Re: [LANG-1478] Do we need to wait for a major release for this one?

[James Carman]

In fact, you don’t even need to change the minor version (assuming this is
the only thing being done). You can just do a “point release”, changing
only the third digit, or 3.9.1

On Sat, Aug 24, 2019 at 9:43 PM Bruno P. Kinoshita  wrote:

>  I think it makes sense, good to go with 3.x then. Thanks sebb!
>
> On Sunday, 25 August 2019, 1:35:41 pm NZST, sebb 
> wrote:
>
>  On Sun, 25 Aug 2019 at 00:57, Bruno P. Kinoshita
>  wrote:
> >
> >  Sorry, wrong PR [1] link:
> https://github.com/apache/commons-lang/pull/445/
> >On Sunday, 25 August 2019, 11:51:47 am NZST, Bruno P. Kinoshita <
> ki...@apache.org> wrote:
> >
> >  Hi,
> > In LANG-1478, a contributor provided a PR for
> ClassUtils.getAbbreviatedName.
> > If you have a class name with 10 characters (e.g. "ab.de.Ghij"), and
> calls the method getAbbreviatedName passing the length argument of 10, you
> get a 9 characters long string back "a.de.Ghij".
> > The Javadoc for the length parameter  states:
> >
> > "len  the desired length of the abbreviated name"
> >
> > In my opinion it confirms the bug. I have tested the code from the
> GitHub PR p1[ and it solves the bug, but given that it will be a backward
> incompatible change (not binary, but behavior), I wonder if it needs a
> major release then? (i.e. 4.x instead of 3.10).
>
> I don't see why it would need a major release.
>
> Fixing any code bug by definition changes behaviour.
> Given that the Javadoc is unambiguous it's clear what the behaviour
> should be, so it's extremely unlikely that anyone is relying on the
> broken behaviour.
>
> > CheersBruno
> > [1] https://github.com/apache/commons-lang/pull/446
> >

Re: [pool] OK to commit?

[James Carman]

If you feel nervous, you can always push a branch or something and let
folks take a look.

On Sat, Jul 20, 2019 at 8:06 PM Matt Sicker  wrote:

> I believe it’s CTR on Pool, so go for it.
>
> On Sat, Jul 20, 2019 at 18:45, Phil Steitz  wrote:
>
> > I am working on a patch for POOL-361.  I think the analysis in the
> > ticket is correct and I think I know how to fix it (move validation into
> > create()).  I think I still have commit karma, but have not committed to
> > commons in quite a while.  Any objections to me committing directly to
> > [pool]?
> >
> > Phil
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> > --
> Matt Sicker 
>

Re: [IMAGING] Add another backward incompatible change pre alpha2

[James Carman]

On Wed, Jun 26, 2019 at 7:15 PM Gary Gregory  wrote:

> We do not have a 1.0, so it is OK to break BC IMO.


+1

Re: [ALL][DRAFT] Apache Commons Board Report for June 2019

[James Carman]

Fair enough.  And very good point.  It only came to mind for me, because of
the work stuff.  Thanks

On Thu, Jun 13, 2019 at 9:09 AM Gary Gregory  wrote:

> On Thu, Jun 13, 2019 at 8:51 AM James Carman 
> wrote:
>
> > SCXML seems to have stalled quite a bit.  I’m not trying to throw shade
> or
> > anything.  People get busy and just don’t have time for open source work.
> > There have been quite a few folks inquiring about it as of lately, but
> not
> > a ton of traction.  My colleagues at work are interested in using it, so
> > I’ve encouraged them to contribute upstream and help out.  If a regular
> > project was in this sort of trouble, the PMC would want to report it.  Do
> > we need to do the same for our sub modules?
> >
>
> Well, the state of SCXML is not unlike some of our other 42 components. I
> do not think we want a health report on each.
>
> Gary
>
>
> >
> > On Thu, Jun 13, 2019 at 8:33 AM Gary Gregory 
> > wrote:
> >
> > > On Thu, Jun 13, 2019 at 8:30 AM James Carman <
> ja...@carmanconsulting.com
> > >
> > > wrote:
> > >
> > > > Should we mention the issues with SCXML2?
> > > >
> > >
> > > Hi James,
> > >
> > > Would you care to be more specific? What text would you include?
> > >
> > > Gary
> > >
> > > >
> > > > On Thu, Jun 13, 2019 at 8:25 AM Gary Gregory  >
> > > > wrote:
> > > >
> > > > > ## Description:
> > > > >  - Apache Commons is an Apache project focused on all aspects of
> > > reusable
> > > > >Java components.
> > > > >
> > > > > ## Issues:
> > > > >  - There are no issues requiring board attention at this time.
> > > > >
> > > > > ## Activity:
> > > > >  - Activity is good with the release of 8 components.
> > > > >
> > > > > ## Health report:
> > > > >  - While we previously reported migration of all active components
> > that
> > > > >remained in Subversion to GitBox, we still have a few clean ups
> to
> > > do.
> > > > >  - The project is healthy and has welcomed a new PMC member.
> > > > >  - We are continuing to improve the release process by updating our
> > > Maven
> > > > >plugins.
> > > > >  - Mailing activity is good and JIRAs and GitHub PRs are addressed
> > in a
> > > > >timely manner for most components.
> > > > >
> > > > > ## PMC changes:
> > > > >
> > > > >  - Currently 39 PMC members.
> > > > >  - Alex Herbert was added to the PMC on Thu May 09 2019
> > > > >
> > > > > ## Committer base changes:
> > > > >
> > > > >  - Currently 148 committers.
> > > > >  - No new committers added in the last 3 months
> > > > >  - Last committer addition was Alex Herbert at Wed Jan 30 2019
> > > > >
> > > > > ## Releases:
> > > > >
> > > > >  - BCEL-6.3.1 was released on Sat Mar 23 2019
> > > > >  - BUILD-PLUGIN-1.10 was released on Wed Mar 13 2019
> > > > >  - CONFIGURATION-2.5 was released on Sun May 26 2019
> > > > >  - CSV-1.7 was released on Tue Jun 04 2019
> > > > >  - IMAGING-1.0-alpha1 was released on Wed May 01 2019
> > > > >  - LANG-3.9 was released on Sat Apr 13 2019
> > > > >  - PARENT-48 was released on Tue Mar 26 2019
> > > > >  - POOL-2.6.2 was released on Wed Apr 10 2019
> > > > >
> > > > > ## JIRA activity:
> > > > >
> > > > >  - 214 JIRA tickets created in the last 3 months
> > > > >  - 174 JIRA tickets closed/resolved in the last 3 months
> > > > >
> > > > > --
> > > > >
> > > > > Gary
> > > > >
> > > >
> > >
> >
>

Re: [ALL][DRAFT] Apache Commons Board Report for June 2019

[James Carman]

SCXML seems to have stalled quite a bit.  I’m not trying to throw shade or
anything.  People get busy and just don’t have time for open source work.
There have been quite a few folks inquiring about it as of lately, but not
a ton of traction.  My colleagues at work are interested in using it, so
I’ve encouraged them to contribute upstream and help out.  If a regular
project was in this sort of trouble, the PMC would want to report it.  Do
we need to do the same for our sub modules?

On Thu, Jun 13, 2019 at 8:33 AM Gary Gregory  wrote:

> On Thu, Jun 13, 2019 at 8:30 AM James Carman 
> wrote:
>
> > Should we mention the issues with SCXML2?
> >
>
> Hi James,
>
> Would you care to be more specific? What text would you include?
>
> Gary
>
> >
> > On Thu, Jun 13, 2019 at 8:25 AM Gary Gregory 
> > wrote:
> >
> > > ## Description:
> > >  - Apache Commons is an Apache project focused on all aspects of
> reusable
> > >Java components.
> > >
> > > ## Issues:
> > >  - There are no issues requiring board attention at this time.
> > >
> > > ## Activity:
> > >  - Activity is good with the release of 8 components.
> > >
> > > ## Health report:
> > >  - While we previously reported migration of all active components that
> > >remained in Subversion to GitBox, we still have a few clean ups to
> do.
> > >  - The project is healthy and has welcomed a new PMC member.
> > >  - We are continuing to improve the release process by updating our
> Maven
> > >plugins.
> > >  - Mailing activity is good and JIRAs and GitHub PRs are addressed in a
> > >timely manner for most components.
> > >
> > > ## PMC changes:
> > >
> > >  - Currently 39 PMC members.
> > >  - Alex Herbert was added to the PMC on Thu May 09 2019
> > >
> > > ## Committer base changes:
> > >
> > >  - Currently 148 committers.
> > >  - No new committers added in the last 3 months
> > >  - Last committer addition was Alex Herbert at Wed Jan 30 2019
> > >
> > > ## Releases:
> > >
> > >  - BCEL-6.3.1 was released on Sat Mar 23 2019
> > >  - BUILD-PLUGIN-1.10 was released on Wed Mar 13 2019
> > >  - CONFIGURATION-2.5 was released on Sun May 26 2019
> > >  - CSV-1.7 was released on Tue Jun 04 2019
> > >  - IMAGING-1.0-alpha1 was released on Wed May 01 2019
> > >  - LANG-3.9 was released on Sat Apr 13 2019
> > >  - PARENT-48 was released on Tue Mar 26 2019
> > >  - POOL-2.6.2 was released on Wed Apr 10 2019
> > >
> > > ## JIRA activity:
> > >
> > >  - 214 JIRA tickets created in the last 3 months
> > >  - 174 JIRA tickets closed/resolved in the last 3 months
> > >
> > > --
> > >
> > > Gary
> > >
> >
>

Re: [ALL][DRAFT] Apache Commons Board Report for June 2019

[James Carman]

Should we mention the issues with SCXML2?

On Thu, Jun 13, 2019 at 8:25 AM Gary Gregory  wrote:

> ## Description:
>  - Apache Commons is an Apache project focused on all aspects of reusable
>Java components.
>
> ## Issues:
>  - There are no issues requiring board attention at this time.
>
> ## Activity:
>  - Activity is good with the release of 8 components.
>
> ## Health report:
>  - While we previously reported migration of all active components that
>remained in Subversion to GitBox, we still have a few clean ups to do.
>  - The project is healthy and has welcomed a new PMC member.
>  - We are continuing to improve the release process by updating our Maven
>plugins.
>  - Mailing activity is good and JIRAs and GitHub PRs are addressed in a
>timely manner for most components.
>
> ## PMC changes:
>
>  - Currently 39 PMC members.
>  - Alex Herbert was added to the PMC on Thu May 09 2019
>
> ## Committer base changes:
>
>  - Currently 148 committers.
>  - No new committers added in the last 3 months
>  - Last committer addition was Alex Herbert at Wed Jan 30 2019
>
> ## Releases:
>
>  - BCEL-6.3.1 was released on Sat Mar 23 2019
>  - BUILD-PLUGIN-1.10 was released on Wed Mar 13 2019
>  - CONFIGURATION-2.5 was released on Sun May 26 2019
>  - CSV-1.7 was released on Tue Jun 04 2019
>  - IMAGING-1.0-alpha1 was released on Wed May 01 2019
>  - LANG-3.9 was released on Sat Apr 13 2019
>  - PARENT-48 was released on Tue Mar 26 2019
>  - POOL-2.6.2 was released on Wed Apr 10 2019
>
> ## JIRA activity:
>
>  - 214 JIRA tickets created in the last 3 months
>  - 174 JIRA tickets closed/resolved in the last 3 months
>
> --
>
> Gary
>

Re: [lang] ArrayUtils.addFirst(T[], T)?

[James Carman]

I like it.  Seems like a logical thing to do.  Another idea would be adding
at an arbitrary index.

On Wed, Jun 12, 2019 at 5:04 PM Gary Gregory  wrote:

> Hi All:
>
> We have org.apache.commons.lang3.ArrayUtils.add(T[], T).
>
> WDYT about adding a method that adds the element at the beginning of the
> new array instead of the end?
>
> Gary
>

Re: [All] Alpha/beta releases

[James Carman]

On Sun, Jun 9, 2019 at 7:36 AM sebb  wrote:

>
> Huh?
> That can still cause jar issues, *precisely because* only one jar will
> reach the Java classpath.
>
> Suppose there is jar1 with API-V1.
> This is depended on by app1 and app2.
>
> Then jar2 is produced with API-V2 (not BC-compatible with API-V1)
> Update app2 to use jar2.
>
> Assuming jar2 is a later version than jar1, the classpath will no
> longer contain jar1.
> However jar1 contains objects needed by app1.
>

My "jar hell" I usually think of is when two different jars are on the
classpath at the same time and they expose the same class name.
You're talking about the transitive dependency "jar hell" which
definitely can happen.  Sorry for my confusion.

So, in order to get two different jars on the classpath at the same
time (which I thought was what the original request was about in order
to compare APIs), you'd need to change the maven coordinates to allow
them to co-exist.  When you do that, you'll need to change the package
names in order to avoid collisions.

If folks are publishing jars for others to consume with alpha/beta
dependencies (which may very well change), I'd think that's really not
a good idea and we should document our alpha/beta releases as such
(although that's a pretty standard understanding).  The other option
is to just keep with SNAPSHOTs and tell folks to point to our snapshot
repository.

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

Re: [All] Alpha/beta releases

[James Carman]

On Sun, Jun 9, 2019 at 5:40 AM Gilles Sadowski  wrote:

>
> Ultimately the PMC still needs to vote on the release, no?
> Hence I don't see what advantage there is in allowing different
> beta policies.  [Of course, no component is required to provide
> a beta release...]
> What the proposal aims to avoid is JAR hell because of beta
> releases that did not change the maven coordinates.
>

JAR hell will not happen (if using maven) when you do not change the
maven coordinates.  Maven will resolve to only one version of the
given maven coordinates.

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

Re: [All] Alpha/beta releases

[James Carman]

On Wed, Jun 5, 2019 at 12:16 PM Gilles Sadowski  wrote:
>
> Case mainly in point is getting to the first release of new components.
> This is happening now for [Imaging], and will be soon (hopefully) for
> [Numbers], [Statistics] and [Geometry].
>

Okay, so the main issue is getting releases out into the hands of
folks sooner rather than later.  That, I can get behind for sure.

> IIUC, the former is going to release a beta version without modifying
> the top-level package name.  This will create the possibility of JAR
> hell (when 1.0 will be out).
>

I think the package rename piece is the part that is throwing me off.
I'd rather release something as "beta" or "alpha" (we've done this
before IIRC) where folks understand that things can change when the
final release comes out.  I would leave the package names intact (they
should be whatever they're going to be in the final release, barring
any reorganization or whatever), however.

> Since we don't have that much review/feedback on these new and/or
> refactored codes, I thought we could be on a safer ground if we first
> release beta version(s) that
>  * won't be subject to JAR hell and
>  * will be easy (i.e. just add the dependency in the POM file) to
>integrate for people kind enough to give it a try.
>[If it's not easy[1], they won't do it.]
>

Unless you also change the maven coordinates, these two flavors of the
same artifact alpha/beta and "real" will not be able to coexist in the
same maven project, so the JAR hell issue isn't possible.  You can't
just change the package names and allow them to coexist.  That's why
we change both when we do a major release.

In all, I really like the spirit of this, but I think the answer would
be to just release them as alphas/betas while keeping everything else
(artifactId/package name) intact.  Release early, release often! :)

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

Re: [All] Alpha/beta releases

[James Carman]

I’m having a hard time understanding the comparing APIs use case.  If I
were to want to try that, I’d create a branch and import the new dependency
version and see what breaks.  The performance part I wouldn’t think I’d use
one code base either.  I’m not suggesting my way is the only or best way,
just explaining why I’m having a hard time understanding what you’re
doing.  Maybe this will be a learning opportunity for me! :)



On Wed, Jun 5, 2019 at 11:33 AM Gilles Sadowski 
wrote:

> Le mer. 5 juin 2019 à 17:04, James Carman  a
> écrit :
> >
> > What sort of comparison are you looking to do within the same code?
> > Performance?
>
> Yes, that's one possibility; another is comparing different APIs.
>
> Gilles
>
> >>>> [...]
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [All] Alpha/beta releases

[James Carman]

What sort of comparison are you looking to do within the same code?
Performance?

On Wed, Jun 5, 2019 at 10:54 AM Gilles Sadowski 
wrote:

> Le mer. 5 juin 2019 à 16:22, sebb  a écrit :
> >
> > On Wed, 5 Jun 2019 at 15:06, Gilles Sadowski 
> wrote:
> > >
> > > Le mer. 5 juin 2019 à 15:59, sebb  a écrit :
> > > >
> > > > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski 
> wrote:
> > > > >
> > > > > Le mer. 5 juin 2019 à 15:18, sebb  a écrit :
> > > > > >
> > > > > > I'm not sure what problem this is trying to solve.
> > > > > >
> > > > > > How is it intended to use the facility?
> > > > >
> > > > > Ideally:
> > > > > $ mvn -Pbetarelease [... other settings ...]
> -Dbetasubversion=alpha1
> > > > > where the latter profile would take care of changing the
> > > > > toplevel package name
> > > > > o.a.c.somecomp
> > > > > to
> > > > > o.a.c.somecomp.alpha1
> > > > >
> > > > > And, if the upcoming version is, say, "2.3", the generated
> > > > > artefact(s) would be:
> > > > >   commons-somecomp-2.3-alpha1
> > > >
> > > > That's not what I intended to ask.
> > > >
> > > > What problem does the ability to readily change the package name
> actually solve?
> > > > And how are the amended packages going to be used?
> > >
> > > Maybe, I don't understand the question.
> > > The purpose is to be able to quickly produce several beta releases that
> > > don't have to be compatible with other beta releases but that can
> coexist
> > > for the purpose of allowing users to compare the impact of the changes.
> >
> > I don't understand how the user can actually test the release unless
> > they also produce code that is likewise shaded to invoke the
> > appropriate version of the package.
>
> Of course, if they want to test "alpha1", they need to depend on it,
> and modify their code accordingly.
>
> > Surely it would be easier to test the code if it used the standard
> > package names, i.e. no need to change the user code?
>
> Yes, but that means that we cannot compare "alpha1" and "alpha2" in
> the same code.
>
> > i.e. take their app, and run it against the relevant alpha- or
> beta-release.
>
> Then the main concern is the possibility of JAR hell (e.g. when several
> "alpha" are in the classpath).
>
> > This is already possible if the user has the ability to compile the
> > component from source.
>
> I think that If we hope to get help from users, we should provide a JAR.
>
> Regards,
> Gilles
>
> >
> > > Gilles
> > >
> > > >
> > > > > Regards,
> > > > > Gilles
> > > > >
> > > > > >
> > > > > > On Tue, 4 Jun 2019 at 17:35, Matt Sicker 
> wrote:
> > > > > > >
> > > > > > > This sounds like a shade feature, yes. However, in order to
> > > > > > > automatically extract the version extra data and detect a
> version
> > > > > > > keyword like "alpha" may require some additional code, though
> maybe
> > > > > > > the shade plugin already supports that.
> > > > > > >
> > > > > > > Alternatively, JUnit 5.x uses a tool called API Guardian for
> marking
> > > > > > > which APIs are stable or not:
> > > > > > > https://github.com/apiguardian-team/apiguardian
> > > > > > >
> > > > > > > On Tue, 4 Jun 2019 at 05:53, Gilles Sadowski <
> gillese...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > Hello.
> > > > > > > >
> > > > > > > > Does someone see a practical way to automate package names
> > > > > > > > and source files conversions so that each all alpha/beta
> releases
> > > > > > > > can be used together (e.g. to compare their behaviours).
> > > > > > > >
> > > > > > > > I mean, for release version "1.0-alpha1", the top-level
> package
> > > > > > > > name "o.a.c.compid" would be turned into
> "o.a.c.compid.alpha1".
> > > > > > > >
> > > > > > > > This would also solve issues with compatibility checkers
> (with the
> > > > > > > > added bonus that JAR hell could never happen).
> > > > > > > >
> > > > > > > > Couldn't the "shade" plugin be put to use (so that all
> artefacts have
> > > > > > > > their top-level package transparently set to
> "o.a.c.compid.alpha1"
> > > > > > > > and all the tools operate on that)?
> > > > > > > >
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Gilles
> > > > > > > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [All] Alpha/beta releases

[James Carman]

Wouldn’t you have a package collision between two different alpha releases?

On Wed, Jun 5, 2019 at 10:56 AM Gilles Sadowski 
wrote:

> Le mer. 5 juin 2019 à 16:47, James Carman  a
> écrit :
> >
> > Ok, what about 1.2?
>
> How is it different?
>
> Gilles
>
> >
> > On Wed, Jun 5, 2019 at 10:44 AM Gilles Sadowski 
> > wrote:
> >
> > > Le mer. 5 juin 2019 à 16:18, James Carman 
> a
> > > écrit :
> > > >
> > > > What happens if/when you want to release a 2.0-alpha1 in the future?
> > >
> > > Hmm, what happens?
> > > [At point, we'd have renamed "o.a.c.compid" to ""o.a.c.compid2".]
> > >
> > > Gilles
> > >
> > > >
> > > > On Tue, Jun 4, 2019 at 6:53 AM Gilles Sadowski  >
> > > wrote:
> > > >
> > > > > Hello.
> > > > >
> > > > > Does someone see a practical way to automate package names
> > > > > and source files conversions so that each all alpha/beta releases
> > > > > can be used together (e.g. to compare their behaviours).
> > > > >
> > > > > I mean, for release version "1.0-alpha1", the top-level package
> > > > > name "o.a.c.compid" would be turned into "o.a.c.compid.alpha1".
> > > > >
> > > > > This would also solve issues with compatibility checkers (with the
> > > > > added bonus that JAR hell could never happen).
> > > > >
> > > > > Couldn't the "shade" plugin be put to use (so that all artefacts
> have
> > > > > their top-level package transparently set to "o.a.c.compid.alpha1"
> > > > > and all the tools operate on that)?
> > > > >
> > > > >
> > > > > Regards,
> > > > > Gilles
> > > > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [All] Alpha/beta releases

[James Carman]

Ok, what about 1.2?

On Wed, Jun 5, 2019 at 10:44 AM Gilles Sadowski 
wrote:

> Le mer. 5 juin 2019 à 16:18, James Carman  a
> écrit :
> >
> > What happens if/when you want to release a 2.0-alpha1 in the future?
>
> Hmm, what happens?
> [At point, we'd have renamed "o.a.c.compid" to ""o.a.c.compid2".]
>
> Gilles
>
> >
> > On Tue, Jun 4, 2019 at 6:53 AM Gilles Sadowski 
> wrote:
> >
> > > Hello.
> > >
> > > Does someone see a practical way to automate package names
> > > and source files conversions so that each all alpha/beta releases
> > > can be used together (e.g. to compare their behaviours).
> > >
> > > I mean, for release version "1.0-alpha1", the top-level package
> > > name "o.a.c.compid" would be turned into "o.a.c.compid.alpha1".
> > >
> > > This would also solve issues with compatibility checkers (with the
> > > added bonus that JAR hell could never happen).
> > >
> > > Couldn't the "shade" plugin be put to use (so that all artefacts have
> > > their top-level package transparently set to "o.a.c.compid.alpha1"
> > > and all the tools operate on that)?
> > >
> > >
> > > Regards,
> > > Gilles
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [All] Alpha/beta releases

[James Carman]

What happens if/when you want to release a 2.0-alpha1 in the future?

On Tue, Jun 4, 2019 at 6:53 AM Gilles Sadowski  wrote:

> Hello.
>
> Does someone see a practical way to automate package names
> and source files conversions so that each all alpha/beta releases
> can be used together (e.g. to compare their behaviours).
>
> I mean, for release version "1.0-alpha1", the top-level package
> name "o.a.c.compid" would be turned into "o.a.c.compid.alpha1".
>
> This would also solve issues with compatibility checkers (with the
> added bonus that JAR hell could never happen).
>
> Couldn't the "shade" plugin be put to use (so that all artefacts have
> their top-level package transparently set to "o.a.c.compid.alpha1"
> and all the tools operate on that)?
>
>
> Regards,
> Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [SCXML] Are we close to ready for a 2.0 release?

[James Carman]

Guess I should have read the archives.  We've already discussed this
back in April.  I believe the out-of-band request came from my
colleague (as well as the request for an RC email today).  Sounds like
we actually are pretty close other than the documentation/site issues.
I have encouraged my colleagues to get involved and start submitting
PRs.  Perhaps we'll get some "new blood" to help revive SCXML.  Thanks
to Ate and Woonsan for their hard work on this library!  The folks at
work are really digging using it!

Thanks,

James

On Fri, May 17, 2019 at 6:00 PM James Carman  wrote:
>
> A coworker of mine was wanting to use SCXML2.  Obviously we can't use
> SNAPSHOTs in production, so I was just wondering if we are close to
> buttoning up 2.0.  If need be, I can offer to help get it out the door
> (it has been a while).
>
> Thanks,
>
> James

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

[SCXML] Are we close to ready for a 2.0 release?

[James Carman]

A coworker of mine was wanting to use SCXML2.  Obviously we can't use
SNAPSHOTs in production, so I was just wondering if we are close to
buttoning up 2.0.  If need be, I can offer to help get it out the door
(it has been a while).

Thanks,

James

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

Resign from PMC...

[James Carman]

I wish to resign from the Apache Commons PMC. Thank you.

Re: [ALL] Volunteers for a Math IPMC?

[James Carman]

Could we start something in the sandbox? It's not modifying existing code.

On Sat, Jun 18, 2016 at 8:43 AM Jörg Schaible  wrote:

> Hi Gilles,
>
> Gilles wrote:
>
> > Hi.
> >
> > On Fri, 17 Jun 2016 16:01:20 -0700, Ted Dunning wrote:
> >> Gilles,
> >>
> >> Thanks for links.
> >>
> >> I just read that (long-winded) thread and I see no consensus that
> >> "Commons
> >> project is not being interested in hosting those components".
> >
> > In line with what I wrote previously, there isn't any consensus on
> > anything
> > within Commons.
> >
> > I'm asking, again, whether I need to initiate a VOTE that would allow
> > me
> > to set up a workspace ("git", etc.) and transfer some code from CM over
> > there.
> > Or can I jut do it?  [Some help with doing that is most welcome.]
>
>
> -1 (and this is a veto)
>
> Not unless the future of the existing CM is clarified and we get (majority
> ?) consensus here on the list.
>
>
> >> It may be that incubation is a good thing for Commons Math, but it
> >> doesn't
> >> seem valid to say that incubation is necessary because CM is being
> >> kicked
> >> out of Commons.
> >
> > Never said so.
> >
> > There is a confusion here: *I* say that CM is dead.
> >
> > It was dead already in early February but nobody noticed because *I*
> > (alone) continued to answer the ML, comment on JIRA reports and commit
> > code.
> >
> > Why I was alone doing that became clear when Luc announced his
> > resignation
> > and the fork.
> >
> > The development situation *will* change because the context *has*
> > changed
> > (unsupported code).
> > CM cannot go on as it did before the fork.
>
>
> And this is exactly the question. For me as PMC member of Commons I have to
> look at all components and it is not the first time that the original
> authors of a component vanishes and it won't be the last. Either new people
> will stay up to carry on (there are already some new ones) or the component
> is moved at some point into dormant state, because it gets obsolete (maybe
> because of the fork, future will tell).
>
> However, we care for all Commons components and their usage in the wild.
> Nearly all of our components are buried deep down in some software stacks
> and therefore we always take care to an extreme extent to compatibility of
> new releases. With your proposal to rip CM into parts you leave the current
> users of CM out in the rain. *You* tell them simply to use your new shiny
> components A and B and for the rest they should stay at old CM (that still
> contains on top the old stuff of A and B). Sorry, but this is not a proper
> scenario for Commons.
>
>
> > Everybody (developers, users, Commons PMC) would be better off with a
> > selected set of new (supported) components because this is something we
> > can easily do *now* (RERO, etc.).
>
>
> Again, this is *your* point of view and it is caused by *your* refusal to
> consider a CM release that contains the existing code base, just because
> this includes also code *you* cannot/will not/have no interest to support
> or
> maintain. Nobody asked the latter of *you*, just to keep the code untouched
> where you have no interest to work with. Nobody would stop you from working
> on the rest.
>
>
> > I'm OK to go through the incubator to do that; but I don't see that it
> > is an easier path.  Surely it looks longer.  And it seems that even the
> > incubator people doubt that it will lead anywhere.
> >
> > Given the uncertain outcome, going through the incubator would be an
> > attempt at rethinking the development of the currently unsupported
> > code.  See e.g.
> >https://issues.apache.org/jira/browse/MATH-172
> > [Or is that out of scope for an incubation proposal?]
>
>
> The incubator seems at least to be an option to go forward with CM.
>
> - Jörg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

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

[James Carman]

We should probably tally the votes at this point, but it is pretty clear
that there is no consensus, unfortunately. I honestly have no idea what to
do at this point. I have limited connectivity today.

On Fri, Jun 17, 2016 at 12:51 PM Benedikt Ritter <brit...@apache.org> wrote:

> James Carman <ja...@carmanconsulting.com> schrieb am Sa., 11. Juni 2016 um
> 05:47 Uhr:
>
> > Since it has been suggested that the previously passing vote should be
> > voided, I propose we vote again to move Commons Math to a TLP:
> >
> > +1 - Yes, move Commons Math to a TLP
> > -1 - No, do not move Commons Math to a TLP
> >
> > The vote will remain open for 72 hours.
> >
>
> +1 for going through incubation and forming a new TLP when the community is
> big enough.
>
>
> >
> > Thank you,
> >
> > James Carman
> >
>

Re: [crypto] On Java 6, really?

[James Carman]

If it's compiled at a higher target version, it's not a drop-in
replacement. They must upgrade their JRE. One might argue that's actually
*less* backward compatible. We've had this debate before. I don't really
care which way we go, but let's make sure we stay true to the philosophy
(if we want to maintain that philosophy).

On Tue, Jun 14, 2016 at 10:57 AM Gary Gregory <garydgreg...@gmail.com>
wrote:

> On Jun 14, 2016 7:51 AM, "James Carman" <ja...@carmanconsulting.com>
> wrote:
> >
> > The trick is if we want to require a major version upgrade to bump JDK
> > levels. That's why you'd want to bump it now if possible.
>
> We've not required major version bumps for Java bumps in the past.
>
> Gary
>
> >
> > On Tue, Jun 14, 2016 at 10:41 AM Matt Sicker <boa...@gmail.com> wrote:
> >
> > > I'd prefer to get to 1.7 as soon as possible, but if the API is ready
> for a
> > > 1.0 release already, we could wait for 1.1 or 1.2 before going full
> 1.7.
> > >
> > > On 14 June 2016 at 06:16, Stian Soiland-Reyes <st...@apache.org>
> wrote:
> > >
> > > > +1 to JDK7 on crypto
> > > > On 14 Jun 2016 10:25 a.m., "Sun, Dapeng" <dapeng@intel.com>
> wrote:
> > > >
> > > > > > Then next release(after 1.0.0) must be a major release you mean?
> > > > > > If there are no potential users looking for JDK 1.6, dropping now
> > > > should
> > > > > be good idea IMO.
> > > > >
> > > > > Thank Uma, I just checked there is no much changes on upgrading JDK
> to
> > > > > 1.7, I think we can upgrade before this release.
> > > > >
> > > > > Is there anyone have other opinions?
> > > > >
> > > > > Regards
> > > > > Dapeng
> > > > >
> > > > > -Original Message-
> > > > > From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com]
> > > > > Sent: Tuesday, June 14, 2016 4:21 PM
> > > > > To: Commons Developers List
> > > > > Subject: Re: [crypto] On Java 6, really?
> > > > >
> > > > > Then next release(after 1.0.0) must be a major release you mean?
> > > > > If there are no potential users looking for JDK 1.6, dropping now
> > > should
> > > > > be good idea IMO.
> > > > >
> > > > > I also remembered that we wanted to mark 1.0.0 release as Alpha
> right?
> > > > > (just a question)
> > > > >
> > > > > Regards,
> > > > > Uma
> > > > >
> > > > > On 6/14/16, 12:27 AM, "Sun, Dapeng" <dapeng@intel.com> wrote:
> > > > >
> > > > > >Thank Gary, Benedikt, Marcelo, sebb, James, Jochen, ecki, Ralph
> and
> > > > > >Matt for all your input.
> > > > > >
> > > > > >How about make a conservative decision: regarding the first
> > > > > >release(1.0.0), we keep the JDK version as 1.6, and we wouldn't
> > > support
> > > > > >JDK 1.6 for the releases after 1.0.0.
> > > > > >
> > > > > >Regards
> > > > > >Dapeng
> > > > > >
> > > > > >-Original Message-
> > > > > >From: Matt Sicker [mailto:boa...@gmail.com]
> > > > > >Sent: Wednesday, June 08, 2016 6:18 AM
> > > > > >To: Commons Developers List
> > > > > >Subject: Re: [crypto] On Java 6, really?
> > > > > >
> > > > > >I'd imagine that close to 100% of users who are on Java 6 are not
> > > > > >upgrading anything else, either, nor would they be adding in new
> > > > > >dependencies. Every Java 6 project I've come across lately has
> been in
> > > > > >legacy maintenance mode (just like Java 6 itself).
> > > > > >
> > > > > >On 7 June 2016 at 16:47, Gary Gregory <garydgreg...@gmail.com>
> wrote:
> > > > > >
> > > > > >> Let's not forget that customers are paying Oracle to get Java 6
> > > > updates.
> > > > > >>
> > > > > >> Gary
> > > > > >> On Jun 7, 2016 1:24 PM, "Ralph Goers" <
> ralph.go...@dslextreme.com
> >
> > > > > >>wrote:
> > > > > >>
> > > > > >> > I really don¹t think the premier &a

Re: [BCEL] Release Candidate on Thursday

[James Carman]

Is it not a showstopper for BCEL itself, though. Do we have a solution to
these two issues readily available? Is it something that we need to noodle
about for a little while and maybe we can just get a release out while we
do that?

On Tue, Jun 14, 2016 at 12:04 PM Mark Roberts <mar...@cs.washington.edu>
wrote:

> 243 is a show stopper for Daikon.  It will continue to be shipped with our
> private version of BCEL if it is not fixed.
>
> > -Original Message-
> > From: James Carman [mailto:ja...@carmanconsulting.com]
> > Sent: Tuesday, June 14, 2016 8:51 AM
> > To: Commons Developers List
> > Subject: Re: [BCEL] Release Candidate on Thursday
> >
> > Are they show stoppers?
> >
> > On Tue, Jun 14, 2016 at 11:50 AM Mark Roberts
> > <mar...@cs.washington.edu>
> > wrote:
> >
> > > I can tell you right now I would vote -1 as you have not picked up the
> > > fix for https://issues.apache.org/jira/browse/BCEL-243.
> > >
> > > Also, I think https://issues.apache.org/jira/browse/BCEL-195 is fixed,
> > > but has not been closed.
> > >
> > >
> > > Thank you,
> > > Mark Roberts
> > >
> > > > -Original Message-
> > > > From: Benedikt Ritter [mailto:brit...@apache.org]
> > > > Sent: Monday, June 13, 2016 11:49 PM
> > > > To: Commons Developers List
> > > > Subject: [BCEL] Release Candidate on Thursday
> > > >
> > > > Hi,
> > > >
> > > > I'm going to try to create an RC for BCEL 6.0 on friday. Please have
> > > > a
> > > look at
> > > > the current state of the code base and report any issues you see.
> > > >
> > > > Thank you!
> > > > Benedikt
> > >
> > >
> > > -
> > > 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: [BCEL] Release Candidate on Thursday

[James Carman]

Are they show stoppers?

On Tue, Jun 14, 2016 at 11:50 AM Mark Roberts 
wrote:

> I can tell you right now I would vote -1 as you have not picked up the fix
> for https://issues.apache.org/jira/browse/BCEL-243.
>
> Also, I think https://issues.apache.org/jira/browse/BCEL-195 is fixed,
> but has not been closed.
>
>
> Thank you,
> Mark Roberts
>
> > -Original Message-
> > From: Benedikt Ritter [mailto:brit...@apache.org]
> > Sent: Monday, June 13, 2016 11:49 PM
> > To: Commons Developers List
> > Subject: [BCEL] Release Candidate on Thursday
> >
> > Hi,
> >
> > I'm going to try to create an RC for BCEL 6.0 on friday. Please have a
> look at
> > the current state of the code base and report any issues you see.
> >
> > Thank you!
> > Benedikt
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: svn commit: r1748347 - in /commons/proper/csv/trunk/src: changes/changes.xml main/java/org/apache/commons/csv/CSVFormat.java test/java/org/apache/commons/csv/CSVPrinterTest.java

[James Carman]

Can folks perhaps combine commons-io to help?

On Tue, Jun 14, 2016 at 11:27 AM Gary Gregory <garydgreg...@gmail.com>
wrote:

> On Jun 14, 2016 5:19 AM, "James Carman" <ja...@carmanconsulting.com>
> wrote:
> >
> > Are Readers that hard to create?
>
> No, but remembering how to do this is a pain:
>
>  File out = ...
>
>  Charset charset = ...
>
>  CSVPrinter printer = new CSVPrinter(new OutputStreamWriter(new
> FileOutputStream(out), charset), format);
> Instead of:
>
> format.print(file, charset);
>
> We can roll these two APIs back out and document that the components only
> provides low-level APIs, forget convenience APIs.
>
> We can also find a better home for these APIs... like where? On the printer
> static side?
>
> Gary
>
> Itv
> >
> > On Tue, Jun 14, 2016 at 2:17 AM Gary Gregory <garydgreg...@gmail.com>
> wrote:
> >
> > > On Mon, Jun 13, 2016 at 11:13 PM, Benedikt Ritter <brit...@apache.org>
> > > wrote:
> > >
> > > > I don't like how we're evolving CSVFormat. It is becoming a dumping
> > > ground
> > > > for anything that may be useful or convenient. The more methods we
> add,
> > > the
> > > > harder it becomes for users to find the right method for their use
> case.
> > > >
> > >
> > > Small is nice, I get that. But how would you do it differently so that
> I
> > > can easily use Paths, Files, URI, and URLs...
> > >
> > > Gary
> > >
> > >
> > > >
> > > > Benedikt
> > > >
> > > > <ggreg...@apache.org> schrieb am Di., 14. Juni 2016 um 07:53 Uhr:
> > > >
> > > > > Author: ggregory
> > > > > Date: Tue Jun 14 05:53:32 2016
> > > > > New Revision: 1748347
> > > > >
> > > > > URL: http://svn.apache.org/viewvc?rev=1748347=rev
> > > > > Log:
> > > > > Add convenience API CSVFormat.print(File, Charset) (JIRA is down
> ATM).
> > > > >
> > > > > Modified:
> > > > > commons/proper/csv/trunk/src/changes/changes.xml
> > > > >
> > > > >
> > > >
> > >
>
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
> > > > >
> > > > >
> > > >
> > >
>
> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
> > > > >
> > > > > Modified: commons/proper/csv/trunk/src/changes/changes.xml
> > > > > URL:
> > > > >
> > > >
> > >
>
> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/changes/changes.xml?rev=1748347=1748346=1748347=diff
> > > > >
> > > > >
> > > >
> > >
>
> ==
> > > > > --- commons/proper/csv/trunk/src/changes/changes.xml (original)
> > > > > +++ commons/proper/csv/trunk/src/changes/changes.xml Tue Jun 14
> > > 05:53:32
> > > > > 2016
> > > > > @@ -40,6 +40,7 @@
> > > > >
> > > > >  
> > > > > > > due-to="Gary
> > > > > Gregory">Update platform requirement from Java 6 to 7.
> > > > > +   due-to="Gary
> > > > > Gregory">Add convenience API CSVFormat.print(File,
> Charset)
> > > > >  
> > > > >  
> > > > > > > due-to="Gary
> > > > > Gregory">Make CSVPrinter.print(Object) GC-free.
> > > > >
> > > > > Modified:
> > > > >
> > > >
> > >
>
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
> > > > > URL:
> > > > >
> > > >
> > >
>
> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java?rev=1748347=1748346=1748347=diff
> > > > >
> > > > >
> > > >
> > >
>
> ==
> > > > > ---
> > > > >
> > > >
> > >
>
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
> > > > > (original)
> > > > > +++
> > > > >
> > > >
> > >

Re: Re: [ALL] About binary compatibility

[James Carman]

Perhaps the new ASM-based replacement for CLIRR could have those as one of
its "components" in its TLP?

On Tue, Jun 14, 2016 at 11:00 AM Matt Benson <gudnabr...@gmail.com> wrote:

> On Jun 14, 2016 9:55 AM, "Gary Gregory" <garydgreg...@gmail.com> wrote:
> >
> >
> > On Jun 14, 2016 7:45 AM, "Matt Benson" <gudnabr...@gmail.com> wrote:
> > >
> > > On Tue, Jun 14, 2016 at 2:14 AM, Andrey Loskutov <losku...@gmx.de>
> wrote:
> > >
> > > > I like the way Eclipse it does for years:
> > > >
> > > > 1) Everything inside **/internal/ packages is non API by definition
> > > > 2) MANIFEST.MF to use OSGI "Export-Package" attribute for "published"
> > > > packages
> > > > 3) Javadoc @noextend tag for classes not intended to be extended
> > > > 4) Javadoc @noimplement tag for interfaces
> > > >
> > > > If "real" annotations were used for points 3 and 4, they could live
> > > alongside a Java (6) Processor that, if the user had annotation
> processing
> > > enabled, could fail the build (pretty sure this is doable).
> >
> > But where do these annotations live? Does each Commons component
> duplicate them?
> >
>
> I thought about that, and would conclude that they should live in a thin
> compile-time-only dependency library (it may be the case that usable
> versions of these annotations already exist someplace, but the processor
> would still have to be provided in this manner, so it doesn't really change
> anything). No reason this couldn't be used outside Commons either,
> actually.
>
> Matt
>
> > Gary
> >
> > >
> > > Matt
> > >
> > >
> > > > A bonus for libraries with correct MANIFEST.MF is that they can be
> > > > directly used as bundles inside any OSGI container (also Eclipse).
> > > >
> > > > Example:
> > > > /**
> > > >  * An observable value whose changes can be vetoed by listeners.
> > > >  *
> > > >  * @param 
> > > >  *the type of value being observed
> > > >  *
> > > >  * @noextend This interface is not intended to be extended by
> clients.
> > > >  * @noimplement This interface is not intended to be implemented by
> > > > clients.
> > > >  *  Clients should instead subclass one of the classes
> that
> > > >  *  implement this interface. Note that direct
> implementers of
> > > > this
> > > >  *  interface outside of the framework will be broken in
> future
> > > >  *  releases when methods are added to this interface.
> > > >  *
> > > >  * @since 1.0
> > > >  *
> > > >  */
> > > > public interface IVetoableValue extends IObservableValue {
> > > >
> > > > Kind regards,
> > > > Andrey Loskutov
> > > >
> > > > http://google.com/+AndreyLoskutov
> > > >
> > > >
> > > > > Gesendet: Dienstag, 14. Juni 2016 um 09:03 Uhr
> > > > > Von: "Jörg Schaible" <joerg.schai...@bpm-inspire.com>
> > > > > An: dev@commons.apache.org
> > > > > Betreff: Re: [ALL] About binary compatibility
> > > > >
> > > > > Hi,
> > > > >
> > > > > James Carman wrote:
> > > > >
> > > > > > Agree we should have a "source of truth". Is there something
> wrong with
> > > > > > using an "internal" or "impl" package name? The bundle plugin for
> OSGi
> > > > > > doesn't export these by default, which would be a nice side
> effect! :).
> > > > >
> > > > > While it is a step in the right direction, a package scoped
> solution does
> > > > > not solve the problem of a public interface that should not be
> > > > implemented
> > > > > directly (as we've seen with the BCEL visitor). Time for Java 8 and
> its
> > > > > default implementations ...
> > > > >
> > > > > Cheers,
> > > > > Jörg
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >
> > > >
>

Re: [crypto] On Java 6, really?

[James Carman]

The trick is if we want to require a major version upgrade to bump JDK
levels. That's why you'd want to bump it now if possible.

On Tue, Jun 14, 2016 at 10:41 AM Matt Sicker  wrote:

> I'd prefer to get to 1.7 as soon as possible, but if the API is ready for a
> 1.0 release already, we could wait for 1.1 or 1.2 before going full 1.7.
>
> On 14 June 2016 at 06:16, Stian Soiland-Reyes  wrote:
>
> > +1 to JDK7 on crypto
> > On 14 Jun 2016 10:25 a.m., "Sun, Dapeng"  wrote:
> >
> > > > Then next release(after 1.0.0) must be a major release you mean?
> > > > If there are no potential users looking for JDK 1.6, dropping now
> > should
> > > be good idea IMO.
> > >
> > > Thank Uma, I just checked there is no much changes on upgrading JDK to
> > > 1.7, I think we can upgrade before this release.
> > >
> > > Is there anyone have other opinions?
> > >
> > > Regards
> > > Dapeng
> > >
> > > -Original Message-
> > > From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com]
> > > Sent: Tuesday, June 14, 2016 4:21 PM
> > > To: Commons Developers List
> > > Subject: Re: [crypto] On Java 6, really?
> > >
> > > Then next release(after 1.0.0) must be a major release you mean?
> > > If there are no potential users looking for JDK 1.6, dropping now
> should
> > > be good idea IMO.
> > >
> > > I also remembered that we wanted to mark 1.0.0 release as Alpha right?
> > > (just a question)
> > >
> > > Regards,
> > > Uma
> > >
> > > On 6/14/16, 12:27 AM, "Sun, Dapeng"  wrote:
> > >
> > > >Thank Gary, Benedikt, Marcelo, sebb, James, Jochen, ecki, Ralph and
> > > >Matt for all your input.
> > > >
> > > >How about make a conservative decision: regarding the first
> > > >release(1.0.0), we keep the JDK version as 1.6, and we wouldn't
> support
> > > >JDK 1.6 for the releases after 1.0.0.
> > > >
> > > >Regards
> > > >Dapeng
> > > >
> > > >-Original Message-
> > > >From: Matt Sicker [mailto:boa...@gmail.com]
> > > >Sent: Wednesday, June 08, 2016 6:18 AM
> > > >To: Commons Developers List
> > > >Subject: Re: [crypto] On Java 6, really?
> > > >
> > > >I'd imagine that close to 100% of users who are on Java 6 are not
> > > >upgrading anything else, either, nor would they be adding in new
> > > >dependencies. Every Java 6 project I've come across lately has been in
> > > >legacy maintenance mode (just like Java 6 itself).
> > > >
> > > >On 7 June 2016 at 16:47, Gary Gregory  wrote:
> > > >
> > > >> Let's not forget that customers are paying Oracle to get Java 6
> > updates.
> > > >>
> > > >> Gary
> > > >> On Jun 7, 2016 1:24 PM, "Ralph Goers" 
> > > >>wrote:
> > > >>
> > > >> > I really don¹t think the premier & extended support dates should
> > > >> > really mean much, except as an indicator of how many users of that
> > > >> > version might still exist.  Basically, no new features are going
> to
> > > >> > be added to Java
> > > >> so I
> > > >> > don¹t think we should be targeting new features there either. If
> > > >> > there
> > > >> is a
> > > >> > bug that needs to be fixed it should be possible to do it on a
> > > >> > branch of the the release for that version of Java.  The web site
> > > >> > should clearly indicate which versions of the component support
> the
> > > >> > appropriate Java versions.
> > > >> >
> > > >> > Ralph
> > > >> >
> > > >> > > On Jun 7, 2016, at 12:26 PM, sebb  wrote:
> > > >> > >
> > > >> > > I have just checked Oracle support for Java 6.
> > > >> > >
> > > >> > > The Support Life for Java 6 has been extended to Dec 2018 [1] I
> > > >> > > think this means that there are critical systems that cannot yet
> > > >> > > be updated to Java 7+.
> > > >> > >
> > > >> > > This does not mean that we should ensure that all Commons code
> > > >> > > still works on Java 6.
> > > >> > > But it should be taken into account when evaluating the pros and
> > > >> > > cons of requiring a later version.
> > > >> > >
> > > >> > > [1]
> > > >> > >
> http://www.oracle.com/technetwork/java/eol-135779.html#extended6
> > > >> > >
> > > >> > > On 7 June 2016 at 20:02, Jochen Wiedmann
> > > >> > > 
> > > >> > wrote:
> > > >> > >>> Gary Gregory  wrote on Tue., 7. Juni
> > > >> > >>> 2016
> > > >> > >>>
> > > >> >  Are we really starting a new component on a dead platform
> like
> > > >> >  Java
> > > >> 6?
> > > >> > >>
> > > >> > >>
> > > >> > >> You are, of course, right, that the component is more than
> > > >> > >> welcome to use another version. OTOH, given our latest
> > > >> > >> experiences: Is this really someting, that we should care for?
> > > >> > >> IMO, let the component have, whatever they want.
> > > >> > >>
> > > >> > >> Jochen
> > > >> > >>
> > > >> > >>
> 
> > > >> > >> -
> > > >> > >>  To unsubscribe, e-mail:
> 

Re: svn commit: r1748347 - in /commons/proper/csv/trunk/src: changes/changes.xml main/java/org/apache/commons/csv/CSVFormat.java test/java/org/apache/commons/csv/CSVPrinterTest.java

[James Carman]

Are Readers that hard to create?

On Tue, Jun 14, 2016 at 2:17 AM Gary Gregory  wrote:

> On Mon, Jun 13, 2016 at 11:13 PM, Benedikt Ritter 
> wrote:
>
> > I don't like how we're evolving CSVFormat. It is becoming a dumping
> ground
> > for anything that may be useful or convenient. The more methods we add,
> the
> > harder it becomes for users to find the right method for their use case.
> >
>
> Small is nice, I get that. But how would you do it differently so that I
> can easily use Paths, Files, URI, and URLs...
>
> Gary
>
>
> >
> > Benedikt
> >
> >  schrieb am Di., 14. Juni 2016 um 07:53 Uhr:
> >
> > > Author: ggregory
> > > Date: Tue Jun 14 05:53:32 2016
> > > New Revision: 1748347
> > >
> > > URL: http://svn.apache.org/viewvc?rev=1748347=rev
> > > Log:
> > > Add convenience API CSVFormat.print(File, Charset) (JIRA is down ATM).
> > >
> > > Modified:
> > > commons/proper/csv/trunk/src/changes/changes.xml
> > >
> > >
> >
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
> > >
> > >
> >
> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
> > >
> > > Modified: commons/proper/csv/trunk/src/changes/changes.xml
> > > URL:
> > >
> >
> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/changes/changes.xml?rev=1748347=1748346=1748347=diff
> > >
> > >
> >
> ==
> > > --- commons/proper/csv/trunk/src/changes/changes.xml (original)
> > > +++ commons/proper/csv/trunk/src/changes/changes.xml Tue Jun 14
> 05:53:32
> > > 2016
> > > @@ -40,6 +40,7 @@
> > >
> > >  
> > > due-to="Gary
> > > Gregory">Update platform requirement from Java 6 to 7.
> > > +  Add convenience API CSVFormat.print(File, Charset)
> > >  
> > >  
> > > due-to="Gary
> > > Gregory">Make CSVPrinter.print(Object) GC-free.
> > >
> > > Modified:
> > >
> >
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
> > > URL:
> > >
> >
> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java?rev=1748347=1748346=1748347=diff
> > >
> > >
> >
> ==
> > > ---
> > >
> >
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
> > > (original)
> > > +++
> > >
> >
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
> > > Tue Jun 14 05:53:32 2016
> > > @@ -28,10 +28,14 @@ import static org.apache.commons.csv.Con
> > >  import static org.apache.commons.csv.Constants.SP;
> > >  import static org.apache.commons.csv.Constants.TAB;
> > >
> > > +import java.io.File;
> > > +import java.io.FileOutputStream;
> > >  import java.io.IOException;
> > > +import java.io.OutputStreamWriter;
> > >  import java.io.Reader;
> > >  import java.io.Serializable;
> > >  import java.io.StringWriter;
> > > +import java.nio.charset.Charset;
> > >  import java.sql.ResultSet;
> > >  import java.sql.ResultSetMetaData;
> > >  import java.sql.SQLException;
> > > @@ -864,6 +868,27 @@ public final class CSVFormat implements
> > >  }
> > >
> > >  /**
> > > + * Prints to the specified output.
> > > + *
> > > + * 
> > > + * See also {@link CSVPrinter}.
> > > + * 
> > > + *
> > > + * @param out
> > > + *the output
> > > + * @param charset
> > > + *A charset
> > > + * @return a printer to an output
> > > + * @throws IOException
> > > + * thrown if the optional header cannot be printed.
> > > + * @since 1.5
> > > + */
> > > +public CSVPrinter print(final File out, Charset charset) throws
> > > IOException {
> > > +// The FileWriter will be closed when close() is called.
> > > +return new CSVPrinter(new OutputStreamWriter(new
> > > FileOutputStream(out), charset), this);
> > > +}
> > > +
> > > +/**
> > >   * Prints the {@code value} as the next value on the line to
> {@code
> > > out}. The value will be escaped or encapsulated
> > >   * as needed. Useful when one wants to avoid creating CSVPrinters.
> > >   *
> > >
> > > Modified:
> > >
> >
> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
> > > URL:
> > >
> >
> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java?rev=1748347=1748346=1748347=diff
> > >
> > >
> >
> ==
> > > ---
> > >
> >
> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
> > > (original)
> > > +++
> > >
> >
> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
> > > Tue Jun 14 05:53:32 2016
> > > @@ -22,9 +22,12 @@ import static org.junit.Assert.assertArr
> > >  import static 

Re: [DISCUSS] Brining clirr to the ASF?

[James Carman]

+1 to Jochen's idea and I'd love to contribute to that effort!

On Tue, Jun 14, 2016 at 2:40 AM Jochen Wiedmann 
wrote:

> On Tue, Jun 14, 2016 at 8:23 AM, Gary Gregory 
> wrote:
>
> >> as Jochen has pointed out, Clirr seems to be unmaintained. However we
> build
> >> a good part of our release strategy upon clirr. So I wonder whether we
> >> should foster bringing clirr to the ASF (for example by going through
> >> incubation). We're probably not the only ASF project using Clirr.
> >>
> >
> > +1. Can we bring in code that's under GNU Lesser General Public and make
> it
> > ASL 2?
> >
> > Could fit under a new Commons Build or Clirr component since it is a
> > "common" build requirement.
>
> As Clirr is internally based on BCEL, I'd rather see us build a new
> tool on top of ASM, which is very well maintained. Besides, that would
> solve the license problem.
>
> Jochen
>
>
> --
> The next time you hear: "Don't reinvent the wheel!"
>
>
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [ALL] About binary compatibility

[James Carman]

Agree we should have a "source of truth". Is there something wrong with
using an "internal" or "impl" package name? The bundle plugin for OSGi
doesn't export these by default, which would be a nice side effect! :).

On Mon, Jun 13, 2016 at 3:05 PM Thomas Vandahl <t...@apache.org> wrote:

> On 13.06.16 20:57, James Carman wrote:
> > I'd rather not make it (the OSGi metadata) the "source of truth".
>
> I'm not insisting on OSGi meta data but I strongly believe that one
> (single) source of truth is required. Suggest something else.
>
> Bye, Thomas.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [ALL] About binary compatibility

[James Carman]

I'd rather not make it (the OSGi metadata) the "source of truth".

On Mon, Jun 13, 2016 at 2:49 PM Thomas Vandahl <t...@apache.org> wrote:

> On 05.06.16 20:33, James Carman wrote:
> > Not quite. OSGi is a special case. It's much more restrictive than simple
> > J2SE, because it can be. In the general case, the public API for OSGi is
> > different from the public API for J2SE. Let's not confuse the two.
>
> My intention was to use the OSGi meta data to define something that we
> consider a public API. I agree to Sebastian that this might be difficult
> for some components as they were not designed with a separation of
> public and private API in mind. That's why I believe that suing
> something a little more restrictive may help us to move forward and
> improve the situation.
>
> Bye, Thomas.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

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

[James Carman]

You bring up good points (aside from the "scratch" part maybe). I called
for a VOTE again because it was suggested that the previous vote should be
voided.

I'm open to suggestions. I'm just trying to keep this thing from dying and
I figured the Incubator could help us. We haven't done a great job in
building a healthy community around Math in Commons this far, so I'm
looking for alternatives. If it stays here, it is in all likelihood dead.
The one core person we have left has been shot down on almost everything he
has tried to do it seems.

I don't really have any dog in this race. I don't know any of these people
personally (I did meet Phil at ACNA last year and really enjoyed that) ,
but I do feel like we really haven't given Gilles a very fair time here and
in the spirit of a "do-acracy", I felt compelled to help, since he really
is all that is left. I have always felt like Math deserved its own TLP,
anyway, and we voted at one point to go there.

At this point, if the PMC really feels like leaving well enough alone with
Math, I'm fine with that and we can cancel this vote. I do feel, however,
that this PMC/Community is "broken" (for lack of a better term) and I have
felt that way for quite some time. I haven't felt compelled to contribute
code (only oversight) to this project for a long time. Obviously with
recent events, something is wrong and we need to come to grips with what
that is. I know others share some of my feelings, but I'll let them share
should they choose to do so.

I'll stop rambling. I'm sure this is enough to ruffle some feathers.

On Sun, Jun 12, 2016 at 5:34 PM Dennis E. Hamilton <dennis.hamil...@acm.org>
wrote:

> -1 (non-binding)
>
> Reason for objection:
>
>  I think the framing of this vote is confusing.
>
>  1. There appears to be less ability to go to TLP than there was at the
> time the previous motion passed.
>
>  2. The discussion (but not the [VOTE]) speaks of going to TLP via the
> incubator.  It has to be one or the other.  Propose a podling to Incubator
> or propose a TLP to the Board.  There is no assurance that a podling will
> graduate and it doesn't fit to make that a condition.  One could raise the
> special circumstances at general-incubator, but I think that works best
> with something specific (but malleable) in hand.
>
>  3. The Incubator is reluctant to start podlings from scratch, as Niall
> observes.
>
>  4. It seems to me that the best first-step on whether incubation is
> feasible is to do the work to create an incubation proposal.  This will
> require certain key factors to be addressed.  Not the least is how the code
> base will be imported and, because it is from an Apache Project, how it
> will be left behind too.  That definition can start here and then be
> refined on the general-incubator list where one will need to find a
> champion (perhaps), mentors, and a sufficient body of initial committers.
> It is important for those who would form the initial core for a podling to
> learn enough about how incubation works.
>
>  - Dennis
>
> Disclosure:
>
>  I have no idea how this might go.  I am not a Commons Math subject-matter
> expert, even though computational mathematics has some appeal for me.  I
> still have my bound "Collect Algorithms from ACM, Volume 1: Algorithms
> 1-220."  I did not hold onto the microfiche of later algorithms that were
> published in conjunction with the ACM Transactions on Mathematical Software
> (TOMS). The latest (Algorithm 959) is interesting although I have no idea
> where to find the code and am dismayed that it is a library under the GPL.
>
> > -Original Message-
> > From: Niall Pemberton [mailto:niall.pember...@gmail.com]
> > Sent: Sunday, June 12, 2016 11:56
> > To: Commons Developers List <dev@commons.apache.org>
> > Subject: Re: [VOTE] Move Commons Math to TLP (again)...
> >
> > On Sat, Jun 11, 2016 at 10:39 AM, James Carman
> > <ja...@carmanconsulting.com>
> > wrote:
> >
> > > We would take math through the incubator in order to build community
> > around
> > > it first. If we fail to do so, then we can decide its fate at that
> > time. We
> > > haven't done a good job attracting new people to math here at all. It
> > has
> > > always been maintained primarily by a select few.
> > >
> >
> > It made sense to me when there were 6 committers working on Math, but I
> > think given the exodus of most of those people to hipparchus then it
> > would
> > be better to wait a while for the dust to settle to see what happens
> > with
> > Math.
> >
> > I also don't think the incubator is a good place for starting a
> > community
> > from scratch 

Re: svn commit: r1748015 - in /commons/proper/imaging/trunk/src: changes/changes.xml main/java/org/apache/commons/imaging/formats/pnm/PnmImageParser.java test/java/org/apache/commons/imaging/formats/p

[James Carman]

That's still a tough one (breakfast). Crazy weekend.

It looks like the switch (which to me is more readable) does a hashCode()
call first to find the right place to jump to and then does equals. So,
theoretically it would be faster, especially for large numbers of cases
(unless the compiler is smart enough to recognize when it's effectively a
switch implemented as ifs). It would be interesting to see how well it get
optimized away at runtime though (if I wasn't on vacation tomorrow I might
play with that a bit). It would also be interesting to see the compiled
bytecode side-by-side for the Sun compiler.
On Sun, Jun 12, 2016 at 5:49 PM Gary Gregory <garydgreg...@gmail.com> wrote:

> On Jun 12, 2016 2:45 PM, "James Carman" <ja...@carmanconsulting.com>
> wrote:
> >
> > I don't off the top of my head. All I have is anecdotal stuff in my
> brain,
> > but then again I can't remember what I had for lunch yesterday either. :)
>
> How about breakfast this morning? ;-)
>
> Gary
> >
> > On Sun, Jun 12, 2016 at 5:42 PM dbrosIus <dbros...@baybroadband.net>
> wrote:
> >
> > > Sure I got that.  I thought you had a source that explains an if/else
> > > chain getting jitted down to a simple hash jumptable
> > >
> > >  Original message 
> > > From: James Carman <ja...@carmanconsulting.com>
> > > Date: 06/12/2016  5:19 PM  (GMT-05:00)
> > > To: Commons Developers List <dev@commons.apache.org>
> > > Subject: Re: svn commit: r1748015 - in
> /commons/proper/imaging/trunk/src:
> > > changes/changes.xml
> > > main/java/org/apache/commons/imaging/formats/pnm/PnmImageParser.java
> > >
> test/java/org/apache/commons/imaging/formats/pnm/PnmImageParserTest.java
> > >
> > > I was referring to JIT.
> > >
> > > On Sun, Jun 12, 2016 at 5:18 PM dbrosIus <dbros...@baybroadband.net>
> > > wrote:
> > >
> > > > Interesting.  Source?
> > > >
> > > >  Original message 
> > > > From: James Carman <ja...@carmanconsulting.com>
> > > > Date: 06/12/2016  5:12 PM  (GMT-05:00)
> > > > To: Commons Developers List <dev@commons.apache.org>
> > > > Subject: Re: svn commit: r1748015 - in
> /commons/proper/imaging/trunk/src:
> > > > changes/changes.xml
> > > > main/java/org/apache/commons/imaging/formats/pnm/PnmImageParser.java
> > > >
> test/java/org/apache/commons/imaging/formats/pnm/PnmImageParserTest.java
> > > >
> > > > Doesn't it all compiled down to the same thing? It gets optimized at
> > > > runtime anyway. I would go for the more readable option, unless there
> are
> > > > extremely compelling performance numbers.
> > > >
> > > > On Sun, Jun 12, 2016 at 4:38 PM Benedikt Ritter <brit...@apache.org>
> > > > wrote:
> > > >
> > > > > Yes, the if-else could also be implemented using a switch
> statement.
> > > But
> > > > is
> > > > > that really more efficient?
> > > > >
> > > > > Benedikt
> > > > >
> > > > > Gary Gregory <garydgreg...@gmail.com> schrieb am So., 12. Juni
> 2016
> um
> > > > > 22:05:
> > > > >
> > > > > > This looks like a candidate for the more efficient switch on
> string.
> > > > > >
> > > > > > Gary
> > > > > >
> > > > > > On Sun, Jun 12, 2016 at 7:47 AM, <brit...@apache.org> wrote:
> > > > > >
> > > > > > > Author: britter
> > > > > > > Date: Sun Jun 12 14:47:11 2016
> > > > > > > New Revision: 1748015
> > > > > > >
> > > > > > > URL: http://svn.apache.org/viewvc?rev=1748015=rev
> > > > > > > Log:
> > > > > > > IMAGING-178: PnmImageParser does not check the validity of
> input
> > > PAM
> > > > > > > header. Thanks to emopers. This also fixes #20 from github.
> > > > > > >
> > > > > > > Modified:
> > > > > > > commons/proper/imaging/trunk/src/changes/changes.xml
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
>
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/pnm/PnmImageParser.java
> > > > > > >
> > > &g

Re: svn commit: r1748015 - in /commons/proper/imaging/trunk/src: changes/changes.xml main/java/org/apache/commons/imaging/formats/pnm/PnmImageParser.java test/java/org/apache/commons/imaging/formats/p

[James Carman]

I don't off the top of my head. All I have is anecdotal stuff in my brain,
but then again I can't remember what I had for lunch yesterday either. :)

On Sun, Jun 12, 2016 at 5:42 PM dbrosIus <dbros...@baybroadband.net> wrote:

> Sure I got that.  I thought you had a source that explains an if/else
> chain getting jitted down to a simple hash jumptable
>
>  Original message ----
> From: James Carman <ja...@carmanconsulting.com>
> Date: 06/12/2016  5:19 PM  (GMT-05:00)
> To: Commons Developers List <dev@commons.apache.org>
> Subject: Re: svn commit: r1748015 - in /commons/proper/imaging/trunk/src:
> changes/changes.xml
> main/java/org/apache/commons/imaging/formats/pnm/PnmImageParser.java
> test/java/org/apache/commons/imaging/formats/pnm/PnmImageParserTest.java
>
> I was referring to JIT.
>
> On Sun, Jun 12, 2016 at 5:18 PM dbrosIus <dbros...@baybroadband.net>
> wrote:
>
> > Interesting.  Source?
> >
> >  Original message 
> > From: James Carman <ja...@carmanconsulting.com>
> > Date: 06/12/2016  5:12 PM  (GMT-05:00)
> > To: Commons Developers List <dev@commons.apache.org>
> > Subject: Re: svn commit: r1748015 - in /commons/proper/imaging/trunk/src:
> > changes/changes.xml
> > main/java/org/apache/commons/imaging/formats/pnm/PnmImageParser.java
> > test/java/org/apache/commons/imaging/formats/pnm/PnmImageParserTest.java
> >
> > Doesn't it all compiled down to the same thing? It gets optimized at
> > runtime anyway. I would go for the more readable option, unless there are
> > extremely compelling performance numbers.
> >
> > On Sun, Jun 12, 2016 at 4:38 PM Benedikt Ritter <brit...@apache.org>
> > wrote:
> >
> > > Yes, the if-else could also be implemented using a switch statement.
> But
> > is
> > > that really more efficient?
> > >
> > > Benedikt
> > >
> > > Gary Gregory <garydgreg...@gmail.com> schrieb am So., 12. Juni 2016 um
> > > 22:05:
> > >
> > > > This looks like a candidate for the more efficient switch on string.
> > > >
> > > > Gary
> > > >
> > > > On Sun, Jun 12, 2016 at 7:47 AM, <brit...@apache.org> wrote:
> > > >
> > > > > Author: britter
> > > > > Date: Sun Jun 12 14:47:11 2016
> > > > > New Revision: 1748015
> > > > >
> > > > > URL: http://svn.apache.org/viewvc?rev=1748015=rev
> > > > > Log:
> > > > > IMAGING-178: PnmImageParser does not check the validity of input
> PAM
> > > > > header. Thanks to emopers. This also fixes #20 from github.
> > > > >
> > > > > Modified:
> > > > > commons/proper/imaging/trunk/src/changes/changes.xml
> > > > >
> > > > >
> > > >
> > >
> >
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/pnm/PnmImageParser.java
> > > > >
> > > > >
> > > >
> > >
> >
> commons/proper/imaging/trunk/src/test/java/org/apache/commons/imaging/formats/pnm/PnmImageParserTest.java
> > > > >
> > > > > Modified: commons/proper/imaging/trunk/src/changes/changes.xml
> > > > > URL:
> > > > >
> > > >
> > >
> >
> http://svn.apache.org/viewvc/commons/proper/imaging/trunk/src/changes/changes.xml?rev=1748015=1748014=1748015=diff
> > > > >
> > > > >
> > > >
> > >
> >
> ==
> > > > > --- commons/proper/imaging/trunk/src/changes/changes.xml (original)
> > > > > +++ commons/proper/imaging/trunk/src/changes/changes.xml Sun Jun 12
> > > > > 14:47:11 2016
> > > > > @@ -46,6 +46,9 @@ The  type attribute can be add,u
> > > > >
> > > > >
> > > > >  
> > > > > +   > > > > due-to="emopers">
> > > > > +PnmImageParser does not check the validity of input PAM
> > > header.
> > > > > +  
> > > > >
> > > > >  Update platform from Java 5 to 7
> > > > >
> > > > >
> > > > > Modified:
> > > > >
> > > >
> > >
> >
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/pnm/PnmImageParser.java
> > > > > URL:

Re: svn commit: r1748015 - in /commons/proper/imaging/trunk/src: changes/changes.xml main/java/org/apache/commons/imaging/formats/pnm/PnmImageParser.java test/java/org/apache/commons/imaging/formats/p

[James Carman]

I was referring to JIT.

On Sun, Jun 12, 2016 at 5:18 PM dbrosIus <dbros...@baybroadband.net> wrote:

> Interesting.  Source?
>
>  Original message ----
> From: James Carman <ja...@carmanconsulting.com>
> Date: 06/12/2016  5:12 PM  (GMT-05:00)
> To: Commons Developers List <dev@commons.apache.org>
> Subject: Re: svn commit: r1748015 - in /commons/proper/imaging/trunk/src:
> changes/changes.xml
> main/java/org/apache/commons/imaging/formats/pnm/PnmImageParser.java
> test/java/org/apache/commons/imaging/formats/pnm/PnmImageParserTest.java
>
> Doesn't it all compiled down to the same thing? It gets optimized at
> runtime anyway. I would go for the more readable option, unless there are
> extremely compelling performance numbers.
>
> On Sun, Jun 12, 2016 at 4:38 PM Benedikt Ritter <brit...@apache.org>
> wrote:
>
> > Yes, the if-else could also be implemented using a switch statement. But
> is
> > that really more efficient?
> >
> > Benedikt
> >
> > Gary Gregory <garydgreg...@gmail.com> schrieb am So., 12. Juni 2016 um
> > 22:05:
> >
> > > This looks like a candidate for the more efficient switch on string.
> > >
> > > Gary
> > >
> > > On Sun, Jun 12, 2016 at 7:47 AM, <brit...@apache.org> wrote:
> > >
> > > > Author: britter
> > > > Date: Sun Jun 12 14:47:11 2016
> > > > New Revision: 1748015
> > > >
> > > > URL: http://svn.apache.org/viewvc?rev=1748015=rev
> > > > Log:
> > > > IMAGING-178: PnmImageParser does not check the validity of input PAM
> > > > header. Thanks to emopers. This also fixes #20 from github.
> > > >
> > > > Modified:
> > > > commons/proper/imaging/trunk/src/changes/changes.xml
> > > >
> > > >
> > >
> >
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/pnm/PnmImageParser.java
> > > >
> > > >
> > >
> >
> commons/proper/imaging/trunk/src/test/java/org/apache/commons/imaging/formats/pnm/PnmImageParserTest.java
> > > >
> > > > Modified: commons/proper/imaging/trunk/src/changes/changes.xml
> > > > URL:
> > > >
> > >
> >
> http://svn.apache.org/viewvc/commons/proper/imaging/trunk/src/changes/changes.xml?rev=1748015=1748014=1748015=diff
> > > >
> > > >
> > >
> >
> ==
> > > > --- commons/proper/imaging/trunk/src/changes/changes.xml (original)
> > > > +++ commons/proper/imaging/trunk/src/changes/changes.xml Sun Jun 12
> > > > 14:47:11 2016
> > > > @@ -46,6 +46,9 @@ The  type attribute can be add,u
> > > >
> > > >
> > > >  
> > > > +   > > > due-to="emopers">
> > > > +PnmImageParser does not check the validity of input PAM
> > header.
> > > > +  
> > > >
> > > >  Update platform from Java 5 to 7
> > > >
> > > >
> > > > Modified:
> > > >
> > >
> >
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/pnm/PnmImageParser.java
> > > > URL:
> > > >
> > >
> >
> http://svn.apache.org/viewvc/commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/pnm/PnmImageParser.java?rev=1748015=1748014=1748015=diff
> > > >
> > > >
> > >
> >
> ==
> > > > ---
> > > >
> > >
> >
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/pnm/PnmImageParser.java
> > > > (original)
> > > > +++
> > > >
> > >
> >
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/pnm/PnmImageParser.java
> > > > Sun Jun 12 14:47:11 2016
> > > > @@ -157,18 +157,28 @@ public class PnmImageParser extends Imag
> > > >  final String type = tokenizer.nextToken();
> > > >  if ("WIDTH".equals(type)) {
> > > >  seenWidth = true;
> > > > +if(!tokenizer.hasMoreTokens())
> > > > +throw new ImageReadException("PAM header has
> > no
> > > > WIDTH value");
> 

Re: svn commit: r1748015 - in /commons/proper/imaging/trunk/src: changes/changes.xml main/java/org/apache/commons/imaging/formats/pnm/PnmImageParser.java test/java/org/apache/commons/imaging/formats/p

[James Carman]

Doesn't it all compiled down to the same thing? It gets optimized at
runtime anyway. I would go for the more readable option, unless there are
extremely compelling performance numbers.

On Sun, Jun 12, 2016 at 4:38 PM Benedikt Ritter  wrote:

> Yes, the if-else could also be implemented using a switch statement. But is
> that really more efficient?
>
> Benedikt
>
> Gary Gregory  schrieb am So., 12. Juni 2016 um
> 22:05:
>
> > This looks like a candidate for the more efficient switch on string.
> >
> > Gary
> >
> > On Sun, Jun 12, 2016 at 7:47 AM,  wrote:
> >
> > > Author: britter
> > > Date: Sun Jun 12 14:47:11 2016
> > > New Revision: 1748015
> > >
> > > URL: http://svn.apache.org/viewvc?rev=1748015=rev
> > > Log:
> > > IMAGING-178: PnmImageParser does not check the validity of input PAM
> > > header. Thanks to emopers. This also fixes #20 from github.
> > >
> > > Modified:
> > > commons/proper/imaging/trunk/src/changes/changes.xml
> > >
> > >
> >
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/pnm/PnmImageParser.java
> > >
> > >
> >
> commons/proper/imaging/trunk/src/test/java/org/apache/commons/imaging/formats/pnm/PnmImageParserTest.java
> > >
> > > Modified: commons/proper/imaging/trunk/src/changes/changes.xml
> > > URL:
> > >
> >
> http://svn.apache.org/viewvc/commons/proper/imaging/trunk/src/changes/changes.xml?rev=1748015=1748014=1748015=diff
> > >
> > >
> >
> ==
> > > --- commons/proper/imaging/trunk/src/changes/changes.xml (original)
> > > +++ commons/proper/imaging/trunk/src/changes/changes.xml Sun Jun 12
> > > 14:47:11 2016
> > > @@ -46,6 +46,9 @@ The  type attribute can be add,u
> > >
> > >
> > >  
> > > +   > > due-to="emopers">
> > > +PnmImageParser does not check the validity of input PAM
> header.
> > > +  
> > >
> > >  Update platform from Java 5 to 7
> > >
> > >
> > > Modified:
> > >
> >
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/pnm/PnmImageParser.java
> > > URL:
> > >
> >
> http://svn.apache.org/viewvc/commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/pnm/PnmImageParser.java?rev=1748015=1748014=1748015=diff
> > >
> > >
> >
> ==
> > > ---
> > >
> >
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/pnm/PnmImageParser.java
> > > (original)
> > > +++
> > >
> >
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/pnm/PnmImageParser.java
> > > Sun Jun 12 14:47:11 2016
> > > @@ -157,18 +157,28 @@ public class PnmImageParser extends Imag
> > >  final String type = tokenizer.nextToken();
> > >  if ("WIDTH".equals(type)) {
> > >  seenWidth = true;
> > > +if(!tokenizer.hasMoreTokens())
> > > +throw new ImageReadException("PAM header has
> no
> > > WIDTH value");
> > >  width = Integer.parseInt(tokenizer.nextToken());
> > >  } else if ("HEIGHT".equals(type)) {
> > >  seenHeight = true;
> > > +if(!tokenizer.hasMoreTokens())
> > > +throw new ImageReadException("PAM header has
> no
> > > HEIGHT value");
> > >  height = Integer.parseInt(tokenizer.nextToken());
> > >  } else if ("DEPTH".equals(type)) {
> > >  seenDepth = true;
> > > +if(!tokenizer.hasMoreTokens())
> > > +throw new ImageReadException("PAM header has
> no
> > > DEPTH value");
> > >  depth = Integer.parseInt(tokenizer.nextToken());
> > >  } else if ("MAXVAL".equals(type)) {
> > >  seenMaxVal = true;
> > > +if(!tokenizer.hasMoreTokens())
> > > +throw new ImageReadException("PAM header has
> no
> > > MAXVAL value");
> > >  maxVal = Integer.parseInt(tokenizer.nextToken());
> > >  } else if ("TUPLTYPE".equals(type)) {
> > >  seenTupleType = true;
> > > +if(!tokenizer.hasMoreTokens())
> > > +throw new ImageReadException("PAM header has
> no
> > > TUPLTYPE value");
> > >  tupleType.append(tokenizer.nextToken());
> > >  } else if ("ENDHDR".equals(type)) {
> > >  break;
> > >
> > > Modified:
> > >
> >
> commons/proper/imaging/trunk/src/test/java/org/apache/commons/imaging/formats/pnm/PnmImageParserTest.java
> > > URL:
> > >
> >
> 

Re: [LANG] Would CircuitBreaker better fit into [NET]?

[James Carman]

Can it be used in non-I/O situations?

On Sun, Jun 12, 2016 at 8:15 AM sebb <seb...@gmail.com> wrote:

> IO is a better fit than NET, but I'm not sure that it is better than LANG.
>
> On 12 June 2016 at 13:03, James Carman <ja...@carmanconsulting.com> wrote:
> > It has general stream/reader stuff too.
> >
> > On Sun, Jun 12, 2016 at 7:53 AM Benedikt Ritter <brit...@apache.org>
> wrote:
> >
> >> Pascal Schumacher <pascalschumac...@gmx.net> schrieb am So., 12. Juni
> 2016
> >> um 13:50 Uhr:
> >>
> >> > Yes, so I guess Commons IO would be the best fit.
> >> >
> >>
> >> Really? When talking about I/O I always think about file system
> >> operations...
> >>
> >>
> >> >
> >> > Am 12.06.2016 um 13:40 schrieb James Carman:
> >> > > Is it only I/O related?
> >> > >
> >> > > On Sun, Jun 12, 2016 at 7:05 AM Benedikt Ritter <brit...@apache.org
> >
> >> > wrote:
> >> > >
> >> > >> Hi,
> >> > >>
> >> > >> CircuitBreaker is a pattern usually used when working with remote
> >> > systems.
> >> > >> We have a CircuitBreaker implementation added to [LANG] in the
> >> > concurrent
> >> > >> package. Now I'm wondering whether it would better fit into [NET].
> >> > >>
> >> > >> Thoughts?
> >> > >>
> >> > >> Benedikt
> >> > >>
> >> >
> >> >
> >> > -
> >> > 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: [LANG] Would CircuitBreaker better fit into [NET]?

[James Carman]

It has general stream/reader stuff too.

On Sun, Jun 12, 2016 at 7:53 AM Benedikt Ritter <brit...@apache.org> wrote:

> Pascal Schumacher <pascalschumac...@gmx.net> schrieb am So., 12. Juni 2016
> um 13:50 Uhr:
>
> > Yes, so I guess Commons IO would be the best fit.
> >
>
> Really? When talking about I/O I always think about file system
> operations...
>
>
> >
> > Am 12.06.2016 um 13:40 schrieb James Carman:
> > > Is it only I/O related?
> > >
> > > On Sun, Jun 12, 2016 at 7:05 AM Benedikt Ritter <brit...@apache.org>
> > wrote:
> > >
> > >> Hi,
> > >>
> > >> CircuitBreaker is a pattern usually used when working with remote
> > systems.
> > >> We have a CircuitBreaker implementation added to [LANG] in the
> > concurrent
> > >> package. Now I'm wondering whether it would better fit into [NET].
> > >>
> > >> Thoughts?
> > >>
> > >> Benedikt
> > >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: [LANG] Would CircuitBreaker better fit into [NET]?

[James Carman]

Is it only I/O related?

On Sun, Jun 12, 2016 at 7:05 AM Benedikt Ritter  wrote:

> Hi,
>
> CircuitBreaker is a pattern usually used when working with remote systems.
> We have a CircuitBreaker implementation added to [LANG] in the concurrent
> package. Now I'm wondering whether it would better fit into [NET].
>
> Thoughts?
>
> Benedikt
>

[ALL] Volunteers for a Math IPMC?

[James Carman]

We (the Commons PMC) have not decided yet what to do, but I just wanted to
gauge the interest in joining the math IPMC if we choose to go TLP by way
of the incubator. The idea would be that math (whatever its name may be),
would go through the incubator in order to enrich its community prior to
becoming a TLP. Do we have any folks willing to throw their hat in the ring?

p.s. I've cross-posted to the incubator list as there are folks there who
are very good at this stuff and could perhaps lend us some advice.

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

[James Carman]

We would take math through the incubator in order to build community around
it first. If we fail to do so, then we can decide its fate at that time. We
haven't done a good job attracting new people to math here at all. It has
always been maintained primarily by a select few.

On Sat, Jun 11, 2016 at 1:36 AM Ralph Goers <ralph.go...@dslextreme.com>
wrote:

> -1 (binding)
>
> At least until there are enough people to have a viable PMC.
>
> Ralph
>
> > On Jun 10, 2016, at 8:47 PM, James Carman <ja...@carmanconsulting.com>
> wrote:
> >
> > Since it has been suggested that the previously passing vote should be
> > voided, I propose we vote again to move Commons Math to a TLP:
> >
> > +1 - Yes, move Commons Math to a TLP
> > -1 - No, do not move Commons Math to a TLP
> >
> > The vote will remain open for 72 hours.
> >
> > Thank you,
> >
> > James Carman
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Math] Commons Math (r)evolution

[James Carman]

On Sat, Jun 11, 2016 at 12:48 AM James Carman <ja...@carmanconsulting.com>
wrote:

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

Re: [Math] Commons Math (r)evolution

[James Carman]

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

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

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

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

Re: [Math] Commons Math (r)evolution

[James Carman]

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

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

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

+1 from me.

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

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

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

[James Carman]

Here's my +1 (binding).

On Fri, Jun 10, 2016 at 11:47 PM James Carman <ja...@carmanconsulting.com>
wrote:

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

Re: [Math] Commons Math (r)evolution

[James Carman]

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

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

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

[James Carman]

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

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

The vote will remain open for 72 hours.

Thank you,

James Carman

Re: [Math] Commons Math (r)evolution

[James Carman]

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

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

Re: [Math] Commons Math (r)evolution

[James Carman]

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



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

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

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

[James Carman]

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

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


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


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

Re: [Math] Commons Math (r)evolution

[James Carman]

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

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

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

[James Carman]

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

On Fri, Jun 10, 2016 at 8:57 AM James Carman <ja...@carmanconsulting.com>
wrote:

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

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

[James Carman]

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

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

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

Re: [crypto] Logging dependency

[James Carman]

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

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

Re: [Math] Commons Math (r)evolution

[James Carman]

Exactly!
On Thu, Jun 9, 2016 at 10:54 PM Ralph Goers <ralph.go...@dslextreme.com>
wrote:

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

Re: [Math] Commons Math (r)evolution

[James Carman]

TLP TLP TLP!

You can split it up into whatever you want.

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

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

Re: [crypto] Logging dependency

[James Carman]

I'll check it out. The printf sounds nice
On Thu, Jun 9, 2016 at 7:18 PM Ralph Goers <ralph.go...@dslextreme.com>
wrote:

>
> > On Jun 9, 2016, at 3:55 PM, James Carman <ja...@carmanconsulting.com>
> wrote:
> >
> > On Thu, Jun 9, 2016 at 2:19 PM Matt Sicker <boa...@gmail.com> wrote:
> >
> >> There is a huge list of advantages to using log4j-api over slf4j-api
> >> nowadays, plus I do prefer to use Apache dependencies in Apache projects
> >> unless the competition is clearly better for the use case (like using
> Jetty
> >> instead of Tomcat in Karaf due to OSGi support). Also, using log4j-api
> >> works fine with logback as well, so it's not like it prevents people
> from
> >> using slf4j bindings at runtime.
> >>
> >>
> > It's just my personal preference.  I have grown used to it and use it so
> > much.  In Karaf (where I spend most of my time these days), I don't even
> > have to think about it.
>
> That is understandable. But you should really compare the APIs. Just as
> SLF4J is much better than Commons Logging, so too is Log4j’s API much
> better than SLF4J’s - at least in the opinion of those who develop Log4j.
>
> Also, SLF4J advertises 2 key features - parameterized log statements and
> Markers.  However, SLF4J markers are a mess. The code isn’t thread safe and
> has terrible performance (which you can see on the Log4j performance page).
> Log4j also supports parameterized logging, but it also supports using
> printf style strings, MessageFormat strings as well as logging Messages
> instead of Strings. And, of course, it supports Lamda’s, which goes even
> further into not needing to wrap logging statements in if isEnabled checks.
>
> And as Gary mentioned, we intentionally created a bridge from Log4j’s API
> to SLF4J for those who want to use some other implementation.
>
> Ralph
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [crypto] Logging dependency

[James Carman]

On Thu, Jun 9, 2016 at 2:19 PM Matt Sicker  wrote:

> There is a huge list of advantages to using log4j-api over slf4j-api
> nowadays, plus I do prefer to use Apache dependencies in Apache projects
> unless the competition is clearly better for the use case (like using Jetty
> instead of Tomcat in Karaf due to OSGi support). Also, using log4j-api
> works fine with logback as well, so it's not like it prevents people from
> using slf4j bindings at runtime.
>
>
It's just my personal preference.  I have grown used to it and use it so
much.  In Karaf (where I spend most of my time these days), I don't even
have to think about it.

Re: [BCEL6] StackMapTable / StackMapTableEntry gone

[James Carman]

Let's be clear here.  We are proposing changing the code because someone
used a SNAPSHOT version and released their code which uses it?  That code
was never released and I don't know that it's right to bind us to a
work-in-progress.  It's bad enough we have to be saddled forever with the
burden of backward compatibility on code we release.

On the other hand, we've done a very poor job of releasing the library, so
folks did what they had to do to get the new features/fixes.  So, there
definitely are two sides to this situation.

On Wed, Jun 8, 2016 at 5:17 AM sebb  wrote:

> On 8 June 2016 at 10:01, Andrey Loskutov  wrote:
> > On Wednesday 08 June 2016 08:37 Benedikt Ritter wrote:
> >> Hallo Andrey,
> >>
> >> Andrey Loskutov  schrieb am Mi., 8. Juni 2016 um
> 09:36 Uhr:
> >>
> >> > Hi,
> >> >
> >> > I'm following the package rename and trying to fix compile issues with
> >> > BCEL6 in FindBugs.
> >> >
> >> > Before 6.0 we had both StackMap and StackMapTable classes (with
> >> > StackMapEntry / StackMapTableEntry elements).
> >> > This was added via https://issues.apache.org/jira/browse/BCEL-92 to
> >> > support Java 6.
> >> >
> >> > Now in trunk I see that StackMapTable and  StackMapTableEntry were
> >> > removed, via https://issues.apache.org/jira/browse/BCEL-248.
> >> >
> >> > This causes few compile issues in FindBugs, and I see also no reason
> why
> >> > it should be removed either.
> >> >
> >> > Unfortunately, Java 1.6 documentation [3] doesn't mentioned neither
> >> > StackMapTable nor StackMap attributes (or I'm unable to find it).
> >> > The official JVM documentation for Java SE 1.7 /1.8 mentions only
> >> > StackMapTable attribute, see [1,2].
> >> > StackMap attribute seems to be mentioned in Java ME  specs, see [3].
> >> > In ASM code I see StackMap seem to be used for classfile versions <
> 50 (<
> >> > Java 6) and StackMapTable otherwise.
> >> >
> >> > If I understand it right, *both* attributes can appear in class
> files, and
> >> > StackMapTable is the one we have to deal with most the time on a
> standard
> >> > Java >= 6.
> >> >
> >> > So  please can we restore the state where we have StackMapTable /
> >> > StackMapTableEntry classes , to avoid further confusion and API
> breakage in
> >> > BCEL6?
> >> >
> >>
> >> I'm confused. As far as I can tell those classes don't show up in the
> >> latest Clirr report [1]. I don't understand why they are missing. Any
> idea?
> >
> > A-ha, that surprises me too now, but after some software archaeology it
> is clear why: the latest official 5.2 release is from June 3 2006, which of
> course never "officially" supported Java 6 released in 2006-12-23.
> >
> > The Java 6 StackMapTable support was added to BCEL 2008 (via BCEL-92),
> but there were not a single BCEL release since 2006, so the change was
> never officially published!
> >
> > FindBugs used a BCEL 5.2 trunk *snapshot*, which included those BCEL-92
> changes. I see for example commit from 2010 which added reference to the
> StackMapTable type:
> https://github.com/findbugsproject/findbugs/commit/ea9d699ab042f691740ef59aedd365ba27fb27f8
> .
> >
> > So that's really not nice. I don't know what the best way to fix it.
>
> OK, so what options are there?
>
> A) add the classes back in, but deprecate the class(es) and defer to
> the new implementation if possible
> B) Update Findbugs to use the new design
>
> Anything else?
>
> ==
>
> If the choice is between A and B, then B seems better since it looks
> like FindBugs will need some other updates anyway.
> However if changing Findbugs would break the plugin API then I think A
> would be a better choice.
>
> I think we need to be pragmatic about the design of any code added to
> the replacement for 5.2.
> Yes, we should strive for good design, but if that breaks downstream
> usage in a way that cannot be fixed, then we should do what works best
> overall.
>
> >> Benedikt
> >>
> >> [1] http://commons.apache.org/proper/commons-bcel/clirr-report.html
> >>
> >>
> >> >
> >> > [1]
> >> >
> https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.7.4
> >> > [2]
> >> >
> https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.7.4
> >> > [3]
> >> >
> https://docs.oracle.com/javase/specs/jvms/se6/html/ClassFile.doc.html#43817
> >> > [4]
> >> >
> http://docs.oracle.com/javame/config/cldc/opt-pkgs/api/cldc/api/Appendix1-verifier.pdf
> >> >
> >> > --
> >> > Kind regards,
> >> > google.com/+AndreyLoskutov
> >> >
> >> > -
> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> > For additional commands, e-mail: dev-h...@commons.apache.org
> >> >
> >> >
> >
> > --
> > Kind regards,
> > google.com/+AndreyLoskutov
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: 

Re: [crypto] Logging dependency

[James Carman]

On Mon, Jun 6, 2016 at 10:01 PM Gary Gregory  wrote:

> Hi All:
>
> IMO. if [crypto] is to have a dependency on a logging framework, it should
> be Log4j 2, not Commons Logging. Log4j 2 has an API module, which you can
> pair with any number of implementations: Log4j's own Core, JUL, SLF4J, and
> so on.
>
>
I would prefer SLF4J, personally.  It is by far the most popular based on
my experience with the libraries that I use.  This is assuming the
component does use a logging framework.  Others have suggested that it does
not.  I don't know that it really matters to me one way or the other, but I
do know that in the past when I didn't have any logging when things went
bump, it was hard to determine what to do to fix it.  Some folks keep JMX
stats and the like to help and I suppose that's an option.

Re: [crypto] On Java 6, really?

[James Carman]

+1
On Tue, Jun 7, 2016 at 1:11 PM Benedikt Ritter  wrote:

> Hello Sebb,
>
> sebb  schrieb am Di., 7. Juni 2016 um 18:09 Uhr:
>
> > Does the project *need* to use any Java7 features?
> >
> > Is it working OK now with Java 6 as the minimum?
> >
> > If the answers are No and Yes then moving to Java 7 seems to me to be
> > unnecessary for the initial release.
> >
>
> I think people have expressed in various ways that they don't want to work
> on projects which are stuck on dead Java version. I think we have to
> respect this.
>
> Benedikt
>
>
> >
> >
> > On 7 June 2016 at 16:49, Marcelo Vanzin  wrote:
> > > I thought there was a discussion after the project was set up to move
> to
> > Java 7?
> > >
> > > That being said I see that the pom still defines 1.6 as the target...
> > >
> > > On Mon, Jun 6, 2016 at 7:18 PM, Gary Gregory 
> > wrote:
> > >> Are we really starting a new component on a dead platform like Java 6?
> > >>
> > >> Gary
> > >>
> > >> --
> > >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > >> Java Persistence with Hibernate, Second Edition
> > >> 
> > >> JUnit in Action, Second Edition 
> > >> Spring Batch in Action 
> > >> Blog: http://garygregory.wordpress.com
> > >> Home: http://garygregory.com/
> > >> Tweet! http://twitter.com/GaryGregory
> > >
> > >
> > >
> > > --
> > > Marcelo
> > >
> > > -
> > > 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: BCEL 6 API breakage

[James Carman]

On Tue, Jun 7, 2016 at 8:15 AM Jochen Wiedmann 
wrote:

> In the light of the current discussions, you may be right.
>
> However, what I still don't understand: Why is BC such an issue for people?
>
> I think, it is perfectly reasonable to do, what other projects do:
>
> - Maintain several release branches.
> - Depending on the branch, limit yourself to binary compatible changes, or
> not.
> - Whenever binary incompatibilities are desirable: Create a new
> branch, and start to
>   publish releases out of that branch.
>
> So, what is the big deal?
>
>
I totally agree with you, but it is as if this community has a seemingly
"maintain backward compatibility at all costs" mentality which can be
tremendously stifling to innovation.  We should be able to maintain (and we
have to for security patches) multiple release streams (2 or 3 seems
reasonable).  Obviously there's a balance we have to maintain, but I think
we have been way too far on one side of the spectrum for far too long.
People just aren't having much fun any more.  For a completely
volunteer-based work force, fun is important.

Re: BCEL 6 API breakage

[James Carman]

We have to be willing to reevaluate the BC stringency we have had. Is it
working for our users? Is it worth the trouble it causes (people have left
this community over it)? Are there better options? Is it too strict and
could just be relaxed?

Our BC policies sound good on paper and do address things like "jar hell"
very well, but we definitely are out on the fringe. We are the fanatics
when it comes to BC.

On Tue, Jun 7, 2016 at 5:40 AM sebb  wrote:

> On 7 June 2016 at 03:50, Charles Honton  wrote:
> > How Apache Commons BCEL got to where it is currently.
> >
> > 1. I wanted to release a version of BCEL which would support Java 6 and
> 7.
> > 2. I updated several classes that handled the new instructions and new
> code attributes.
> > 3. This required new methods on several interfaces.
> > 4. These new methods broke binary compatibility.
>
> However, there are ways around this.
> 1) assume code will use the abstract implementations
> 2) use Java 8 default implementations in the interface
> 3) use a sub-interface
> 4) handle the exceptions at run-time
>
> > 5. Whenever binary compatibility is broken, Apache Commons policy is to
> update the Maven GAV to prevent jar hell.
>
> Not exactly, see below.
>
> > 6. Part of updating GAV is to also update the package names.
>
> Avoiding Jar hell for non-Maven users requires package name changes.
> For Maven users the GA coords must correspond 1-1 with Java packages
> otherwise Maven cannot determine which jars can co-exist safely on the
> classpath.
>
> > 7. I created a release candidate which was deemed unsuitable for several
> reasons; mostly due to FindBugs warnings.
> > 8. Multiple refactorings were completed (including moving Interface to
> Class) to handle FindBugs warnings.
> > 9. Refactoring died out after no response from users as to Apache
> direction.
> > 10. Recent new interest has us revisiting these changes.
> >
> > At this point, we’re somewhat stuck.
> > 1. Do we break Apache Commons Policy regarding binary compatibility GAV
> and package names?
>
> Please, no.
>
> > 2. Do we ignore the FindBugs warnings?
> >
> > Personally, I am against either of those.  I also believe that to fix
> BCEL correctly, we’ll end up with an api sufficiently different that users
> will have a non-trivial porting task.  It might be saner if Apache Commons
> moves BCEL into the attic and suggest that our clients to migrate to either
> ASM or JavaAssist.
>
> As I point out above, there are ways to avoid breaking compatibility.
> This requires extra effort, but makes the update much simpler for end
> users.
>
> i.e. it's a trade-off between Commons developer time and everyone else's
> time.
>
> > regards,
> > chas
> >
> >> On Jun 6, 2016, at 11:27 AM, Andrey Loskutov  wrote:
> >>
> >> Hi all,
> >>
> >> this is a follow up on
> https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2016-June/004282.html
> .
> >>
> >> I'm cross-posting this to dev@commons.apache.org because the
> discussion on FindBugs mailing list is related to the BCEL 6 API future,
> and because I would like to know the opinions from the BCEL community on
> the upcoming BCEL 6 release compatibility story.
> >>
> >> Please see my answers inline.
> >>
> >> On Monday 06 June 2016 17:30 sebb wrote:
> >>> On 6 June 2016 at 16:23, Andrey Loskutov  wrote:
>  Hi all,
> 
>  here is the current state of FindBugs adoption to Java 9.
> 
>  1) FindBugs standalone/Eclipse plugin run fine now on/with Java 9,
> the latest code is on java9 branch (not on master yet!), see [0, 1]. If
> there is interest, I can provide binary snapshots.
> 
>  2)  I have difficulties to use BCEL6 trunk, see [2]. Looks like even
> after fixing all compile errors due the various API breakages in BCEL 6
> (see [3]), the current BCEL 6 head can't be used directly as a replacement
> for our old BCEL5.2 fork, see [4]. If anyone from FB and/or BCEL gurus
> could check this, this would be really helpful. Either our BCEL 5.2 patches
> were not fully propagated upstream to BCEL or BCEL 6 trunk has few
> regressions, or I missed something during update? I have no idea, because
> of the next point below. The experimental BCEL 6 port is on an extra branch
> on top of Java 9 related changes, see commits prefixed with BCEL6 on
> java9_bcel6 branch at [5].
> 
>  3) I would be very happy if someone (Bill?) would explain how the
> *current* BCEL5.2 fork used by FindBugs was built? It was added in commit
> [6] but I miss instructions how it differs from the original BCEL code and
> so unable to re-build it.
> 
>  4) Assuming BCEL6 bugs/FB errors would be fixed (see [4]), transition
> to the current BCEL6 head would break each and every FindBugs client,
> because BCEL6 at current state uses different namespace and also added some
> other API breaking changes. If we chose this path, none of the 3rd party
> detectors will work anymore and therefore we 

Re: [BCEL] Move to Git?

[James Carman]

This was proposed long ago.

On Tue, Jun 7, 2016 at 4:46 AM Jochen Wiedmann 
wrote:

> On Tue, Jun 7, 2016 at 10:43 AM, Gary Gregory 
> wrote:
>
> > We have a bunch of components that just got in the queue to migrate from
> > Svn to Git. BCEL would just be another one...
>
> Maybe we could take the discussion for all components now, and would
> just do the actual move componentwise?
>
> - Would spare us a lot of [VOTE][LAZY] mails.
> - At least I don't see anyone opposing.
>
> Jochen
>
>
>
> --
> The next time you hear: "Don't reinvent the wheel!"
>
>
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [BCEL] 5.3 is going to be messy

[James Carman]

+1 Torsten

On Tue, Jun 7, 2016 at 6:17 AM Torsten Curdt  wrote:

> >
> > 1) I don't believe we should force users to migrate their code in
> > order to support java 7/8.
> >
>
> ...and that line of thinking is why it feels like commons projects are
> effectively stuck in the past.
>
> No one needs to upgrade. If your projects live in the past - there are bug
> fix releases.
> But if you want the new shiny then you as well should be OK to put in some
> effort to do so.
> Change should be easy - not just for our user but also for us.
>
> My 2 cents
>

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

[James Carman]

+1

On Tue, Jun 7, 2016 at 2:37 AM Kristian Rosenvold 
wrote:

> Hello,
>
> I'd like to call a VOTE by LAZY
> consensus for migrating the Apache Commons IO component to git. Please
> object to this vote if you see a problem with this. Otherwise this vote
> will be considered as passed after 72 hours from now (10th June 2016, 09:00
> CET)
>
> Thank you,
> Kristian
>

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

[James Carman]

+1

On Mon, Jun 6, 2016 at 3:17 PM Benedikt Ritter  wrote:

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

Re: [ALL] About binary compatibility

[James Carman]

On Sun, Jun 5, 2016 at 7:12 PM Ralph Goers 
wrote:

> I think we should adopt Java 9’s multi-release jars [1] as standard
> practice.  While this won’t let us update our APIs without breaking
> compatibility (which may still be necessary), it will allow us to leverage
> some features in newer versions of Java without worrying about breaking
> backward compatibility.
>
>
When do you propose we adopt this new feature?  As of now, the issue is
still listed as "Unresolved" in their issue tracking:

https://bugs.openjdk.java.net/browse/JDK-8047305

I'm not saying I'm against the idea (on the surface it sounds pretty
interesting).  I'm just saying that it doesn't appear to be an option for
us at present.  We could definitely be one of the early-adopters of this
new feature (one a few select components first) and show folks how it's
done, once it is available.  Common Lang seems like a likely candidate for
such a feature.

Re: [ALL] About binary compatibility

[James Carman]

Not quite. OSGi is a special case. It's much more restrictive than simple
J2SE, because it can be. In the general case, the public API for OSGi is
different from the public API for J2SE. Let's not confuse the two.

On Sun, Jun 5, 2016 at 2:30 PM Gary Gregory  wrote:

> On Jun 5, 2016 11:12 AM, "sebb"  wrote:
> >
> > On 5 June 2016 at 18:51, Thomas Vandahl  wrote:
> > > On 03.06.16 10:38, sebb wrote:
> > >> On 2 June 2016 at 21:42, Benedikt Ritter  wrote:
> > >>> - we must not break BC in a release that could collide with an
> earlier
> > >>> version. In other words, when we break BC, we have to change package
> and
> > >>> maven coordinates.
> > >>
> > >> +1, with the proviso that we must not break BC in the *public* API.
> > >> Unfortunately it is not always clear what is public.
> > >>
> > >
> > > All commons components are released with OSGi bundle metadata, where
> the
> > > packages for a public API can be stated. If this information is
> > > maintained correctly, everyone should be able to tell public from
> > > private API changes.
> >
> > The problem is determining what is supposed to be public, not documenting
> it.
>
> We could document OSGi as how we spec public APIs.
>
> Gary
>
> >
> > Though I would question whether non-OSGi users would think to look at
> > the metadata.
> >
> > > Bye, Thomas.
> > >
> > >
> > >
> > > -
> > > 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: Apache Code of Conduct

[James Carman]

No, only if it is *enforced* will people start to feel safe and throw out
their new ideas. The trick is making people aware that poor behavior won't
be tolerated. Enforcement starts with the community stepping in and saying
"now, that was uncalled for" or "we do not allow personal attacks" or
whatever. Admittedly, we haven't done a good job of this in the past. I'm
all for having this Code of Conduct prominently displayed, but we have to
come together as a community and make it known that it is going to be
observed.

On Sun, Jun 5, 2016 at 5:28 AM Stian Soiland-Reyes  wrote:

> +1, showing the Code of Conduct is important also to encourage
> contributions and engagement from underrepresented groups.
> On 5 Jun 2016 8:47 a.m., "Benedikt Ritter"  wrote:
>
> +1
>
> Gary Gregory  schrieb am So., 5. Juni 2016 um
> 03:04:
>
> > On Sat, Jun 4, 2016 at 5:06 PM, Niall Pemberton <
> niall.pember...@gmail.com
> > >
> > wrote:
> >
> > > On Sun, Jun 5, 2016 at 12:56 AM, Gary Gregory 
> > > wrote:
> > >
> > > > On Sat, Jun 4, 2016 at 4:53 PM, Niall Pemberton <
> > > niall.pember...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Apache has a "Code of Conduct" here:
> > > > > http://www.apache.org/foundation/policies/conduct.html
> > > > >
> > > > > I think we should include a link to it on the Commons Site - does
> > > anyone
> > > > > object to that?
> > > > >
> > > >
> > > > No objection, could it go under "GENERAL INFORMATION" or under the
> > stock
> > > > "ASF" we pick up?
> > > >
> > >
> > > Yes, my preference would be under "ASF" as its an foundation
> doc/policy,
> > >
> >
> > That's my preference as well.
> >
> > Gary
> >
> >
> > >
> > > Niall
> > >
> > >
> > > >
> > > > Gary
> > > >
> > > >
> > > > > Thanks
> > > > >
> > > > > Niall
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > 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
> >
>

Re: [ALL] About binary compatibility

[James Carman]

I don't think it has anything to do necessarily with framework or not. The
class loading model is just much easier to deal with these situations. As
Benson said, however, there are definitely other issues to contend with.
On Thu, Jun 2, 2016 at 6:14 PM Benedikt Ritter <brit...@apache.org> wrote:

> James Carman <ja...@carmanconsulting.com> schrieb am Fr., 3. Juni 2016 um
> 00:04 Uhr:
>
> > You've been in karaf land for too long! ;)
> >
>
> It's probably a different story when you're working on a framework. It
> pretty unlikely to end up with two version of Spring or Hibernate in your
> app. But for a library as wildly used as commons-lang it becomes more
> likely.
>
>
> >
> > On Thu, Jun 2, 2016 at 5:36 PM Benson Margulies <bimargul...@gmail.com>
> > wrote:
> >
> > > I don't understand what's wrong with semantic versioning and keeping
> > > the same maven coordinates. No sane person should be using RELEASE or
> > > LATEST.
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
>

Re: [ALL] About binary compatibility

[James Carman]

Yep, those pesky duplicate chains.
On Thu, Jun 2, 2016 at 6:05 PM Benson Margulies <bimargul...@gmail.com>
wrote:

> On Thu, Jun 2, 2016 at 6:04 PM, James Carman <ja...@carmanconsulting.com>
> wrote:
> > You've been in karaf land for too long! ;)
>
> I took my team into OSGi to get away from these messes. Of course, we
> got some other messes in their places.
>
> >
> > On Thu, Jun 2, 2016 at 5:36 PM Benson Margulies <bimargul...@gmail.com>
> > wrote:
> >
> >> I don't understand what's wrong with semantic versioning and keeping
> >> the same maven coordinates. No sane person should be using RELEASE or
> >> LATEST.
> >>
> >> -
> >> 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: [ALL] About binary compatibility

[James Carman]

You've been in karaf land for too long! ;)

On Thu, Jun 2, 2016 at 5:36 PM Benson Margulies 
wrote:

> I don't understand what's wrong with semantic versioning and keeping
> the same maven coordinates. No sane person should be using RELEASE or
> LATEST.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [math] avoid allocating distribution bounds if there are no successes

[James Carman]

Why not create a release prep branch for each release when ready? The
"gitflow" treatment of master is that's what's currently "in production" or
whatever. I don't really care for that model, but it is popular. For
libraries that support multiple versions, I don't know how realistic that
is.

On Wed, Jun 1, 2016 at 6:25 PM sebb  wrote:

> Given that the 'master' branch is normally where development takes
> place, this problem is going to keep recurring.
>
> Maybe MATH should consider using 'master' as the normal development
> branch and 'release' or somesuch for the release candidate.
>
>
> On 29 May 2016 at 22:42, Gilles  wrote:
> > Hi.
> >
> > Thanks for willing to participate, but the "master" branch should be
> > modified only by merging the "develop" into it (before preparing a
> > release).
> > Cf. rationale in "doc/development/development.howto.txt" (in the
> > "develop" branch).
> >
> > Regards,
> > Gilles
> >
> >
> >
> > On Sun, 29 May 2016 21:28:11 + (UTC), dbros...@apache.org wrote:
> >>
> >> Repository: commons-math
> >> Updated Branches:
> >>   refs/heads/master 91b2f4294 -> 02dd98a04
> >>
> >>
> >> avoid allocating distribution bounds if there are no successes
> >>
> >>
> >> Project: http://git-wip-us.apache.org/repos/asf/commons-math/repo
> >> Commit:
> >> http://git-wip-us.apache.org/repos/asf/commons-math/commit/02dd98a0
> >> Tree: http://git-wip-us.apache.org/repos/asf/commons-math/tree/02dd98a0
> >> Diff: http://git-wip-us.apache.org/repos/asf/commons-math/diff/02dd98a0
> >>
> >> Branch: refs/heads/master
> >> Commit: 02dd98a04570a1beba88566281efcabc8ff6f73d
> >> Parents: 91b2f42
> >> Author: Dave Brosius 
> >> Authored: Sun May 29 17:27:37 2016 -0400
> >> Committer: Dave Brosius 
> >> Committed: Sun May 29 17:27:37 2016 -0400
> >>
> >>
> >> --
> >>  .../math4/stat/interval/ClopperPearsonInterval.java | 16
> 
> >>  1 file changed, 8 insertions(+), 8 deletions(-)
> >>
> >> --
> >>
> >>
> >>
> >>
> >>
> http://git-wip-us.apache.org/repos/asf/commons-math/blob/02dd98a0/src/main/java/org/apache/commons/math4/stat/interval/ClopperPearsonInterval.java
> >>
> >> --
> >> diff --git
> >>
> >>
> >>
> a/src/main/java/org/apache/commons/math4/stat/interval/ClopperPearsonInterval.java
> >>
> >>
> >>
> b/src/main/java/org/apache/commons/math4/stat/interval/ClopperPearsonInterval.java
> >> index bf5d6ad..ed0904c 100644
> >> ---
> >>
> >>
> >>
> a/src/main/java/org/apache/commons/math4/stat/interval/ClopperPearsonInterval.java
> >> +++
> >>
> >>
> >>
> b/src/main/java/org/apache/commons/math4/stat/interval/ClopperPearsonInterval.java
> >> @@ -35,19 +35,19 @@ public class ClopperPearsonInterval implements
> >> BinomialConfidenceInterval {
> >>  IntervalUtils.checkParameters(numberOfTrials,
> >> numberOfSuccesses, confidenceLevel);
> >>  double lowerBound = 0;
> >>  double upperBound = 0;
> >> -final double alpha = (1.0 - confidenceLevel) / 2.0;
> >> -
> >> -final FDistribution distributionLowerBound = new
> >> FDistribution(2 * (numberOfTrials - numberOfSuccesses + 1),
> >> -
> >>  2 * numberOfSuccesses);
> >> +
> >>  if (numberOfSuccesses > 0) {
> >> +final double alpha = (1.0 - confidenceLevel) / 2.0;
> >> +
> >> +final FDistribution distributionLowerBound = new
> >> FDistribution(2 * (numberOfTrials - numberOfSuccesses + 1),
> >> +
> >>  2 * numberOfSuccesses);
> >>  final double fValueLowerBound =
> >> distributionLowerBound.inverseCumulativeProbability(1 - alpha);
> >>  lowerBound = numberOfSuccesses /
> >>   (numberOfSuccesses + (numberOfTrials -
> >> numberOfSuccesses + 1) * fValueLowerBound);
> >> -}
> >>
> >> -final FDistribution distributionUpperBound = new
> >> FDistribution(2 * (numberOfSuccesses + 1),
> >> -
> >>  2 * (numberOfTrials - numberOfSuccesses));
> >> -if (numberOfSuccesses > 0) {
> >> +
> >> +final FDistribution distributionUpperBound = new
> >> FDistribution(2 * (numberOfSuccesses + 1),
> >> +
> >>  2 * (numberOfTrials - numberOfSuccesses));
> >>  final double fValueUpperBound =
> >> distributionUpperBound.inverseCumulativeProbability(1 - alpha);
> >>  upperBound = (numberOfSuccesses + 1) * fValueUpperBound /
> >>   (numberOfTrials - numberOfSuccesses +
> >> (numberOfSuccesses + 1) * fValueUpperBound);
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
> 

Re: [Poll][VFS] Switch to Git

[James Carman]

+1

On Wed, May 25, 2016 at 4:43 PM Bernd Eckenfels 
wrote:

> Hello,
>
> I would like to be able to use Git with the Apache Commons VFS repo. As
> we agreed upon I call out the intention to do this and ask you for your
> oppinion.
>
> Now that we have the 2.1 release out of the way the switch wont affect
> any planned steps.
>
> Anybody opposed to this move? I will probably need a few days to come
> back to this, so this poll with lazy consensus is open for at least 5
> days.
>
> Gruss
> Bernd
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [ALL] Dist layout change to per version directories

[James Carman]

That definitely seems easier. +1. Would that mess up any sort of sync jobs
(maven and stuff)?
On Fri, Apr 15, 2016 at 7:26 PM Gary Gregory  wrote:

> I am OK with anything that makes releasing easier.
>
> Gary
>
> On Fri, Apr 15, 2016 at 4:02 PM, sebb  wrote:
>
> > The dist layout currently splits archives into source/ and binaries/.
> > Where there are multiple active versions, these are all in the same
> > directory.
> >
> > IMO this layout is not ideal any more.
> >
> > It is harder to tidy up old releases (files have to be individually
> > deleted)
> > It is harder to move files from dist/dev to dist/release
> >
> > Are there any disadvantages to allowing the layout to change?
> >
> > Unless there are objections, I propose to update the commons build
> > plugin to support download pages using version ids, e.g. instead of
> > the present layout:
> >
> > lang/source/commons-lang-2.6-src.*
> > lang/source/commons-lang3-3.4-src.*
> > lang/binaries/commons-lang-2.6-bin.*
> > lang/binaries/commons-lang3-3.4-bin.*
> >
> > It would look like:
> >
> > lang/commons-lang-2.6/commons-lang-2.6-[bin|src].*
> > lang/commons-lang3-3.4/commons-lang3-3.4-[bin|src].*
> >
> >
> > Note: I don't think we should move the existing releases
> >
> > The intention is to allow new releases to optionally migrate to the new
> > layout.
> > This would be done on the basis of a new property, e.g.
> > commons.release.layout=version
> > If the property is defined, then the new layout is used; if not, then
> > the current source/binaries layout is used.
> >
> > -
> > 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: Is there an missing bit in the instructions for making a release?

[James Carman]

On Fri, Apr 15, 2016 at 4:13 PM sebb  wrote:

>
> As already explained, this is not possible with Git.
> Infra have disabled updating of certain tags includig the ones used
> for releases.


Sorry, didn't realize if this was something we imposed on ourselves and
asked infra to do for us or if it was an ASF-wide policy.  I like "audit
trail" aspect of keeping the "rc" tags around (as Gary pointed out
elsethread).  Looks like some variation of my "option 2" is still on the
table, then.

Re: Is there an missing bit in the instructions for making a release?

[James Carman]

On Fri, Apr 15, 2016 at 1:43 PM sebb  wrote:

>
> "the regular process" is what is under discussion.
>
>
I meant the regular process used by the maven release plugin.  :)  That's
"regular" to me, because that's what I use all the time.  I think we have
an opportunity to streamline what we do here quite a bit.  One of the main
issues we have here is the assertion that tags must be immutable.  We have
two options that I can see, then (since folks are opposed to "burning"
version numbers):

1.  Make them mutable.  Then we can delete the tags when a release VOTE
fails and go at it again.
2.  Let the maven release plugin create  tags called "rc/foo-1.2.3-rc1" or
whatever while it's staging a release to Nexus for us.  Then, when the
release VOTE passes, we release the staging repository and copy the "rc"
tag to "releases/foo-1.2.3" and call it a day.

Thoughts?

Re: Is there an missing bit in the instructions for making a release?

[James Carman]

On Fri, Apr 15, 2016 at 12:57 PM James Carman <ja...@carmanconsulting.com>
wrote:

> On Fri, Apr 15, 2016 at 12:53 PM sebb <seb...@gmail.com> wrote:
>
>> That is effectively what the final release tag is.
>> We vote on the RC tag, and create the release tag from the successful RC
>> tag.
>>
>>
> Yep, we're not far off.  What I'm proposing is that we try to use the
> Maven Release Plugin to create our releases and push them to a staging
> repository in Nexus for a vote.  If the vote fails, drop the staging repo.
> If we truly want immutable tags, then maybe we just create the release with
> a tag of "foo-1.2.3-rc1" (as someone has pointed out, the release plugin
> can do) and then once (or if) it passes, copy it to "releases/foo-1.2.3".
> I must admit, I haven't RM'd a release in a while, mainly because I found
> it to be extremely painful.  Anything we can do to make that process easier
> could only help us release more often.  Obviously we can't sacrifice
> traceability of the code, but I think we can find a workable solution.
>

Again, we can just stick to the regular process and just "burn" version
numbers for votes that don't pass.  Versions != releases.

Re: Is there an missing bit in the instructions for making a release?

[James Carman]

On Fri, Apr 15, 2016 at 12:53 PM sebb  wrote:

> That is effectively what the final release tag is.
> We vote on the RC tag, and create the release tag from the successful RC
> tag.
>
>
Yep, we're not far off.  What I'm proposing is that we try to use the Maven
Release Plugin to create our releases and push them to a staging repository
in Nexus for a vote.  If the vote fails, drop the staging repo.  If we
truly want immutable tags, then maybe we just create the release with a tag
of "foo-1.2.3-rc1" (as someone has pointed out, the release plugin can do)
and then once (or if) it passes, copy it to "releases/foo-1.2.3".  I must
admit, I haven't RM'd a release in a while, mainly because I found it to be
extremely painful.  Anything we can do to make that process easier could
only help us release more often.  Obviously we can't sacrifice traceability
of the code, but I think we can find a workable solution.

Re: Is there an missing bit in the instructions for making a release?

[James Carman]

On Fri, Apr 15, 2016 at 12:38 PM James Carman <ja...@carmanconsulting.com>
wrote:

> On Fri, Apr 15, 2016 at 11:50 AM Benson Margulies <bimargul...@gmail.com>
> wrote:
>
>>
>> The problem is that this PMC does not want a tag named after the real
>> (not RC) version to come into existence  until after the vote passes.
>>
>>
> Well, that's the thing that is somewhat silly.   The fact that there's a
> "tag" doesn't (or shouldn't) mean something has been "released" by our
> PMC.  With the setup I use, I log into Nexus OSS and basically approve the
> staging repository so that it can be officially released.  So, we could
> create a staging repository for folks to vote (along with the corresponding
> tag).  If the vote fails, we just drop the staging repo.  Now, we could at
> that point decide that we want to remove the tag and fix the version
> numbers in the pom.xml files so that we can try again.  Or, we could just
> use the next version number.  I don't really care one way or another.  We
> could even call out releases specifically by copying the tag to
> "releases/foo-1.2.3" or something.
>

You can refer to our main page on releases here at the ASF:

http://www.apache.org/dev/release-publishing.html

which links to the maven-specific steps here:

http://www.apache.org/dev/publishing-maven-artifacts.html

This outlines a process very similar to what I described above (with the
exception that we're possibly using Git and not Subversion, but the
concepts are the same).

Re: Is there an missing bit in the instructions for making a release?

[James Carman]

On Fri, Apr 15, 2016 at 11:50 AM Benson Margulies 
wrote:

>
> The problem is that this PMC does not want a tag named after the real
> (not RC) version to come into existence  until after the vote passes.
>
>
Well, that's the thing that is somewhat silly.   The fact that there's a
"tag" doesn't (or shouldn't) mean something has been "released" by our
PMC.  With the setup I use, I log into Nexus OSS and basically approve the
staging repository so that it can be officially released.  So, we could
create a staging repository for folks to vote (along with the corresponding
tag).  If the vote fails, we just drop the staging repo.  Now, we could at
that point decide that we want to remove the tag and fix the version
numbers in the pom.xml files so that we can try again.  Or, we could just
use the next version number.  I don't really care one way or another.  We
could even call out releases specifically by copying the tag to
"releases/foo-1.2.3" or something.

Re: Is there an missing bit in the instructions for making a release?

[James Carman]

What is with everyone's aversion to using the Maven Release Plugin?  I
realize that it may not do exactly what we need out of the box, but it's a
very useful tool.  At home, I push a button in my Jenkins setup and it cuts
a new release to the Nexus OSS staging repository awaiting me to finalize
it.  Can we not do a process like that?  Perhaps we just create our own
variant of the release plugin in commons to do our release process?

On Fri, Apr 15, 2016 at 11:33 AM Benson Margulies 
wrote:

> On Fri, Apr 15, 2016 at 11:29 AM, sebb  wrote:
> > Thanks!
> >
> > It also occurs to me that having the RC tag in the POM is not
> > necessarily a problem.
>
>
> If you prefer to modify the doc to tell people how to use the plugin
> so that the net result is the RC tag in the POM, OK. That satisfies my
> ask for a set of instructions that an RM can follow without getting
> into a controversy.
>
> All this will be moot if some other voters don't show up.
>
>
>
>
> >
> > So long as the tag is retained after a successful vote, then does it
> > matter whether the tag in the POM is IO-1.2.3-RC4 or IO-1.2.3 ?
> >
> > On 15 April 2016 at 16:02, Brent Worden  wrote:
> >> I probably won't be much help either as I have never used the plugin
> but,
> >> there is a tag option for the plugin that might help control the SCM tag
> >> that is used.  Of all the options for the plugin listed on
> >>
> https://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html
> ,
> >> the tag* options might meet your needs.
> >>
> >>
> >> Thanks,
> >>
> >> Brent
> >>
> >> On Fri, Apr 15, 2016 at 5:16 AM, Benson Margulies <
> bimargul...@gmail.com>
> >> wrote:
> >>
> >>> On Thu, Apr 14, 2016 at 10:33 PM, sebb  wrote:
> >>> > On 15 April 2016 at 02:19, Benson Margulies 
> >>> wrote:
> >>> >> Sebb,
> >>> >>
> >>> >> I don't know why you think I could distinguish the following
> possible
> >>> >> behaviors of prior RMs with a reasonable level of effort:
> >>> >
> >>> > As I have already said, I don't use the plugin.
> >>> > However I have followed release votes and AFAICR the final tag never
> >>> > been created before the vote completed.
> >>> > In all cases I can remember, the final tag is created once the vote
> >>> > has completed.
> >>> > And I am pretty certain other RMs have used the release plugin.
> >>> >
> >>> > So it seems clear to me that something has gone wrong here.
> >>> >
> >>> > I don't know what, so I think we need input from an RM who has used
> >>> > the release plugin.
> >>> > They should be able to point out what is missing from the
> instructions.
> >>>
> >>> This started when I sent email two days ago saying that I was
> >>> perplexed by the instructions. I only proceeded when no prior RM, or
> >>> anyone else, answered.
> >>>
> >>> Maybe they used -DdryRun=true and then edited. Maybe I'm just being
> >>> obtuse. We'll see.
> >>>
> >>>
> >>>
> >>> >
> >>> >> 1: didn't use the maven-release-plugin
> >>> >> 2: did use the maven-release-plugin and then used svn mvn to rename
> >>> >> the tag it created
> >>> >> 3: did use the maven-release-plugin, typed 'commons-io-2.x-RCy' at
> the
> >>> >> prompt, and released with a pom with an incorrect scm element.
> >>> >> 4: something else I didn't think of.
> >>> >>
> >>> >> I didn't volunteer to be an archaeologist, I volunteered to be a
> >>> >> release manager..
> >>> >>
> >>> >> At best, the doc is, as I wrote to start this conversation,
> >>> >> incomplete, in that it does not give specific instructions for
> >>> >> achieving the PMC's goals using the plugin.
> >>> >>
> >>> >> To me, the following sequence is inoffensive:
> >>> >>
> >>> >> 1: run release:prepare, creating a premature 'real' tag.
> >>> >> 2: svn mv to convert that tag to an -RC tag.
> >>> >> 3: svn mv again to convert it to a (conventionally) immutable 'real
> >>> >> tag' if the vote passes.
> >>> >>
> >>> >> However, what I find inoffensive isn't important here. I'm not a PMC
> >>> >> member here. If this PMC has a strong policy of tag immutability,
> then
> >>> >> this PMC needs to document a procedure that both treats tags as
> >>> >> immutable and creates completely correct poms, including the scm
> >>> >> element that has to anticipate the eventual tag. It could create
> that
> >>> >> policy by erasing any mention of release:prepare, or by filling in
> the
> >>> >> missing details (though I continue to believe that there is no way
> to
> >>> >> make it come out the way you want.)
> >>> >>
> >>> >> Believe me, if I ever RM another commons release, I won't use
> >>> >> release:prepare until and unless someone writes up a step-by-step
> >>> >> guide that leads me to do so in an acceptable way.
> >>> >>
> >>> >> If you examine the 'tags' directory in svn right now, you will see
> >>> >> that it contains what I believe that you want it to contain: no
> >>> >> commons-io-2.5 tag, but rather a 

Re: Whatever happened to commons-io 2.5?

[James Carman]

I don't think we take away karma, just membership to the PMC.

On Mon, Apr 11, 2016 at 12:45 PM Benson Margulies 
wrote:

> I'm a member emeritus. Can I do it without being voted as something else?
>
>
> On Mon, Apr 11, 2016 at 12:33 PM, Gary Gregory 
> wrote:
> > I think we got started and staled a while back. We just need an RM to
> step
> > up or step back in.
> >
> > Gary
> >
> > On Mon, Apr 11, 2016 at 9:30 AM, Benson Margulies  >
> > wrote:
> >
> >> There are bugs marked fixed for years awaiting this release.
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>
> >
> >
> > --
> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > Java Persistence with Hibernate, Second Edition
> > 
> > JUnit in Action, Second Edition 
> > Spring Batch in Action 
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [COLLECTIONS] [DISCUSS] Possible candidate for inclusion in Commons-Collections: OrderedSet (provides composite-key based ordering of a set of values)

[James Carman]

Don't get me wrong.  This is a cool idea and I think we can build upon it.
But, I think we can "stand on the shoulders of giants" a bit here and use
some tools that are already available to us.  The use of reflection in your
code is a little off-putting.  One option to consider would be something
like OGNL.

On Fri, Apr 8, 2016 at 9:53 AM Daniel Vimont <dan...@commonvox.org> wrote:

> Thanks for the suggestion. I will look into emulating OrderedSet
> functionality using the two classes you recommend.
>
> Since all of the materials that I provided may be a bit on the "tl;dr"
> side, I will focus on a single example:
>
> Book class, with the following attribute get-methods:
>   getAuthors -- returns collection of Author objects (a Book may have
> multiple authors)
>   getGenres -- returns collection of Genre objects (a Book may be
> classified in multiple genres)
>   getTitle -- returns a Title object (a Book has only one title)
>
> Order these two Books by a Genre|Author|Title composite-key
>   Book 1:
> Title: Dictionary of the English Language
> Genres: Nonfiction; Reference
> Authors: Merriam, George; Webster, Noah
>   Book 2:
> Title: A Walk in the Woods
> Genres: Nonfiction; Travel; Quest
> Author: Bryson, Bill
>
> Following construction and population of an OrderedSet, invocation of the
> #entrySet method will return the following entries:
>
> *Key-components (composite-key)   Value*
> *==   *
> *Genre   Author   Title   Book*
> *--   --  *
> *Nonfiction  Bryson, Bill A Walk...   Book 2*
> *Nonfiction  Merriam, George  Dictionary...   Book 1*
> *Nonfiction  Webster, NoahDictionary...   Book 1*
> *Quest   Bryson, Bill A Walk...   Book 2*
> *Reference   Merriam, George  Dictionary...   Book 1*
> *Reference   Webster, NoahDictionary...   Book 1*
> *Travel  Bryson, Bill A Walk...   Book 2*
>
>
> On Fri, Apr 8, 2016 at 8:19 PM, James Carman <ja...@carmanconsulting.com>
> wrote:
>
> > Couldn't you achieve the same thing using any SortedSet and
> > CompareToBuilder?
> > On Fri, Apr 8, 2016 at 2:17 AM Daniel Vimont <dan...@commonvox.org>
> wrote:
> >
> > > Hello all,
> > >
> > > I've just published a new extension to the standard Java Collections
> > > Framework to both GitHub and the Maven Central Repository, and am
> > > considering offering it up for possible inclusion in the Apache Commons
> > > Collections package.
> > >
> > > The name of the class is "OrderedSet", which is an abbreviated version
> of
> > > its original working name, "CompositeKeyOrderedSet". As its previous
> > > working name suggests, an OrderedSet provides for composite-key based
> > > ordering of a set of values (analogous to composite-key ordering in a
> > > relational database). To get a better sense of what that actually
> means,
> > > the README text on the project's GitHub page provides a quick overview
> > (or
> > > dive down into the source code on the GitHub page, if you prefer):
> > > https://github.com/dvimont/OrderedSet
> > >
> > > For more thorough end-user documentation, the project's Javadocs can be
> > > consulted:
> > > http://bit.ly/ordered-set
> > >
> > > I realize that "Apache Commons is a Commit-Then-Review community", but
> > > before I go through the steps of preparing a patch for submission I
> > wanted
> > > to get some feedback, if possible, regarding whether this class would
> be
> > > appropriate for inclusion in the Apache Commons Collections package,
> and
> > to
> > > be sure that its core functionality does not duplicate either (a) some
> > > already-existing component of the package or (b) some alternate,
> > well-known
> > > (to all but me!) means of achieving automated composite-key-style
> > ordering
> > > (in Java 1.6+).
> > >
> > > Thanks very much,
> > >
> > > Dan Vimont
> > >
> >
>

Re: [COLLECTIONS] [DISCUSS] Possible candidate for inclusion in Commons-Collections: OrderedSet (provides composite-key based ordering of a set of values)

[James Carman]

Couldn't you achieve the same thing using any SortedSet and
CompareToBuilder?
On Fri, Apr 8, 2016 at 2:17 AM Daniel Vimont  wrote:

> Hello all,
>
> I've just published a new extension to the standard Java Collections
> Framework to both GitHub and the Maven Central Repository, and am
> considering offering it up for possible inclusion in the Apache Commons
> Collections package.
>
> The name of the class is "OrderedSet", which is an abbreviated version of
> its original working name, "CompositeKeyOrderedSet". As its previous
> working name suggests, an OrderedSet provides for composite-key based
> ordering of a set of values (analogous to composite-key ordering in a
> relational database). To get a better sense of what that actually means,
> the README text on the project's GitHub page provides a quick overview (or
> dive down into the source code on the GitHub page, if you prefer):
> https://github.com/dvimont/OrderedSet
>
> For more thorough end-user documentation, the project's Javadocs can be
> consulted:
> http://bit.ly/ordered-set
>
> I realize that "Apache Commons is a Commit-Then-Review community", but
> before I go through the steps of preparing a patch for submission I wanted
> to get some feedback, if possible, regarding whether this class would be
> appropriate for inclusion in the Apache Commons Collections package, and to
> be sure that its core functionality does not duplicate either (a) some
> already-existing component of the package or (b) some alternate, well-known
> (to all but me!) means of achieving automated composite-key-style ordering
> (in Java 1.6+).
>
> Thanks very much,
>
> Dan Vimont
>

Re: [RESULT][VOTE] Accept Chimera as new Apache Commons Component

[James Carman]

Hopefully there are enough PMC members to vote for this when they want to
release it.

On Thu, Mar 24, 2016 at 7:52 AM Benedikt Ritter <brit...@apache.org> wrote:

> Hi all,
>
> 72 hours have passed, so it's time to tally up the votes:
>
> Bernd Eckenfels +1
> Luc Maisonobe +1
> Sergio Fernández +1 (non-binding)
> Uwe Barthel +1 (non-binding)
> Emmanuel Bourg +1
> James Carman -0
> sebb -0.9
> Uma Gangumalla +1 (non-binding)
> Haifeng Chen +1 (non-binding)
> Cheng A Xu +1 (non-binding)
> Dong Chen +1 (non-binding)
> Oliver Heger + 0.5
> Thomas Vandahl +1
> Chris Nauroth +1 (non-binding)
> Kai Zheng +1 (non-binding)
> Gary Gregory +1
> Benedikt Ritter +1
>
> So this vote passes.
>
> I'd like to thank everybody involved in this process. More over I'd like to
> thank James, sebb and Oliver for pointing out their concerns regarding JNI.
> I believe the developers of chimera are capable of delivering high quality
> JNI code. But I think it would be good to add some more documentation about
> how the JNI stuff will be handled.
> Furthermore the discussion about the proposed name "Apache Commons Crypto"
> came up again. For this reason I think it would be good to start a separate
> Name discussion thread.
> I'll prepare an E-Mail discussing the next steps soon.
>
> Regards,
> Benedikt
>
> Benedikt Ritter <brit...@apache.org> schrieb am Mo., 21. März 2016 um
> 09:45 Uhr:
>
> > Hi all,
> >
> > after long discussions I think we have gathered enough information to
> > decide whether we want to accept the Chimera project as a new Apache
> > Commons component.
> >
> > Proposed name: Apache Commons Crypto
> > Proposal text:
> > https://github.com/intel-hadoop/chimera/blob/master/PROPOSAL.html
> > Initial Code Base:  https://github.com/intel-hadoop/chimera/
> > Initial Committers (Names in alphabetical order):
> > - Aaron T. Myers (a...@apache.org, Apache Hadoop PMC, one of the original
> > Crypto dev team in Apache Hadoop)
> > - Andrew Wang (w...@apache.org, Apache Hadoop PMC, one of the original
> > Crypto dev team in Apache Hadoop)
> > - Chris Nauroth (cnaur...@apache.org, Apache Hadoop PMC and active
> > reviewer)
> > - Colin P. McCabe (cmcc...@apache.org, Apache Hadoop PMC, one of the
> > original Crypto dev team in Apache Hadoop)
> > - Dapeng Sun (s...@apache.org, Apache Sentry Committer, Chimera
> > contributor)
> > - Dian Fu (dia...@apache.org, Apache Sqoop Committer, Chimera
> contributor)
> > - Dong Chen (do...@apache.org, Apache Hive Committer,interested on
> > Chimera)
> > - Ferdinand Xu (x...@apache.org, Apache Hive Committer, Chimera
> > contributor)
> > - Haifeng Chen (haifengc...@apache.org, Chimera lead and code
> contributor)
> > - Marcelo Vanzin (Apache Spark Committer, Chimera contributor)
> > - Uma Maheswara Rao G (umamah...@apache.org, Apache Hadoop PMC, One of
> the
> > original Crypto dev/review team in Apache Hadoop)
> > - Yi Liu (y...@apache.org, Apache Hadoop PMC, One of the original Crypto
> > dev/review team in Apache Hadoop)
> >
> > Please review the proposal and vote.
> > This vote will close no sooner than 72 hours from now, i.e. after 0900
> > GMT 24-Mar 2016
> >
> >   [ ] +1 Accept Chimera as new Apache Commons Component
> >   [ ] +0 OK, but...
> >   [ ] -0 OK, but really should fix...
> >   [ ] -1 I oppose this because...
> >
> > Thank you!
> > Benedikt
> >
> >
>

Re: [VOTE] Release Configuration 2.0 based on RC1

[James Carman]

+1 drop ant

On Mon, Mar 21, 2016 at 5:06 PM Oliver Heger 
wrote:

> Hi Benedikt,
>
> Am 21.03.2016 um 09:58 schrieb Benedikt Ritter:
> > Hello Oliver,
> >
> > very nice artifacts, good work.
> >
> > - builds with java 6, 7 and 8
> > - site looks good
> > - reports look good
> >
> > Only thing I found is:
> > - build.xml and build.properties.sample are in the tag but not in the src
> > archive. The ant build can probably be dropped (does it work anyway?). No
> > blocker for me.
> >
> > +1
>
> thanks for the review.
>
> You are right, the ant-related files should be part of the source
> distribution. build.xml should be pretty up-to-date. However,
> maintaining two different build files is a pain and error-prone. The
> trend seems to be dropping the ant build. I would be in favor of this.
>
> Oliver
>
> >
> > Benedikt
> >
> > Oliver Heger  schrieb am So., 20. März
> 2016
> > um 22:42 Uhr:
> >
> >> Hi all,
> >>
> >> after a series of alpha and beta releases, I think we are now ready to
> >> release the final 2.0 version of [configuration]. So this is the
> >> corresponding release vote.
> >>
> >> Configuration 2.0 RC1 is available for review here:
> >> https://dist.apache.org/repos/dist/dev/commons/configuration
> >> (revision 12797)
> >>
> >> Maven artifacts are here:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1143
> >>
> >> Details of changes since 1.10 and the previous beta version are in the
> >> release notes:
> >>
> >>
> >>
> https://dist.apache.org/repos/dist/dev/commons/configuration/RELEASE-NOTES.txt
> >>
> >>
> https://home.apache.org/~oheger/configuration-2.0-rc1/changes-report.html
> >>
> >> Here is the tag:
> >>
> >>
> >>
> http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_2_0_RC1
> >> (revision 1735904)
> >>
> >> Site:
> >>https://home.apache.org/~oheger/configuration-2.0-rc1/
> >> (note some links in the menu are not yet working)
> >>
> >> KEYS:
> >>   http://www.apache.org/dist/commons/KEYS
> >>
> >> Please review the release candidate and vote.
> >> This vote will close no sooner than 72 hours from now, i.e. after 2200
> >> GMT 23-Mar 2016
> >>
> >>   [ ] +1 Release these artifacts
> >>   [ ] +0 OK, but...
> >>   [ ] -0 OK, but really should fix...
> >>   [ ] -1 I oppose this release because...
> >>
> >> Thanks!
> >> Oliver
> >>
> >>
> >>
> >> -
> >> 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] Accept Chimera as new Apache Commons Component

[James Carman]

-0, I don't like the idea of a JNI library.

On Mon, Mar 21, 2016 at 4:45 AM Benedikt Ritter  wrote:

> Hi all,
>
> after long discussions I think we have gathered enough information to
> decide whether we want to accept the Chimera project as a new Apache
> Commons component.
>
> Proposed name: Apache Commons Crypto
> Proposal text:
> https://github.com/intel-hadoop/chimera/blob/master/PROPOSAL.html
> Initial Code Base:  https://github.com/intel-hadoop/chimera/
> Initial Committers (Names in alphabetical order):
> - Aaron T. Myers (a...@apache.org, Apache Hadoop PMC, one of the original
> Crypto dev team in Apache Hadoop)
> - Andrew Wang (w...@apache.org, Apache Hadoop PMC, one of the original
> Crypto dev team in Apache Hadoop)
> - Chris Nauroth (cnaur...@apache.org, Apache Hadoop PMC and active
> reviewer)
> - Colin P. McCabe (cmcc...@apache.org, Apache Hadoop PMC, one of the
> original Crypto dev team in Apache Hadoop)
> - Dapeng Sun (s...@apache.org, Apache Sentry Committer, Chimera
> contributor)
> - Dian Fu (dia...@apache.org, Apache Sqoop Committer, Chimera contributor)
> - Dong Chen (do...@apache.org, Apache Hive Committer,interested on
> Chimera)
> - Ferdinand Xu (x...@apache.org, Apache Hive Committer, Chimera
> contributor)
> - Haifeng Chen (haifengc...@apache.org, Chimera lead and code contributor)
> - Marcelo Vanzin (Apache Spark Committer, Chimera contributor)
> - Uma Maheswara Rao G (umamah...@apache.org, Apache Hadoop PMC, One of the
> original Crypto dev/review team in Apache Hadoop)
> - Yi Liu (y...@apache.org, Apache Hadoop PMC, One of the original Crypto
> dev/review team in Apache Hadoop)
>
> Please review the proposal and vote.
> This vote will close no sooner than 72 hours from now, i.e. after 0900
> GMT 24-Mar 2016
>
>   [ ] +1 Accept Chimera as new Apache Commons Component
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this because...
>
> Thank you!
> Benedikt
>

Re: [crypto][chimera] Next steps

[James Carman]

Still not a fan. My vote stands
On Mon, Feb 22, 2016 at 6:37 PM Gary Gregory <garydgreg...@gmail.com> wrote:

> We already have commons-daemon that has C bits.
>
> Gary
> On Feb 22, 2016 3:27 PM, "James Carman" <ja...@carmanconsulting.com>
> wrote:
>
> > Not a big fan of introducing JNI-based library to Commons. I'm -0
> >
> > On Sat, Feb 20, 2016 at 6:15 AM Benedikt Ritter <brit...@apache.org>
> > wrote:
> >
> > > Hi,
> > >
> > > I'd like to discuss the next steps for moving the Chimera component to
> > > Apache Commons. So far, none of the other PMC members has expressed his
> > or
> > > her thoughts about this. If nobody brings up objections about moving
> the
> > > component to Apache Commons, I'm assuming lazy consensus about this.
> > >
> > > So the next steps would be:
> > > - decide on a name for the new component (my proposal was Apache
> Commons
> > > Crypto)
> > > - move code to an Apache repo (probably git?!)
> > > - request a Jira project
> > > - setup maven build
> > > - setup project website
> > > - work on an initial release under Apache Commons coordinates
> > >
> > > Anything missing?
> > >
> > > Regards,
> > > Benedikt
> > >
> > > --
> > > http://home.apache.org/~britter/
> > > http://twitter.com/BenediktRitter
> > > http://github.com/britter
> > >
> >
>

Re: [crypto][chimera] Next steps

[James Carman]

Not a big fan of introducing JNI-based library to Commons. I'm -0

On Sat, Feb 20, 2016 at 6:15 AM Benedikt Ritter  wrote:

> Hi,
>
> I'd like to discuss the next steps for moving the Chimera component to
> Apache Commons. So far, none of the other PMC members has expressed his or
> her thoughts about this. If nobody brings up objections about moving the
> component to Apache Commons, I'm assuming lazy consensus about this.
>
> So the next steps would be:
> - decide on a name for the new component (my proposal was Apache Commons
> Crypto)
> - move code to an Apache repo (probably git?!)
> - request a Jira project
> - setup maven build
> - setup project website
> - work on an initial release under Apache Commons coordinates
>
> Anything missing?
>
> Regards,
> Benedikt
>
> --
> http://home.apache.org/~britter/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>

Re: [Math] How fast is fast enough?

[James Carman]

Okay, folks, this is definitely getting out of hand. Let's put a moratorium
on this thread for the weekend or something and try to come back together
next week and try to move forward. I would urge folks to watch this while
we wait:

https://m.youtube.com/watch?v=rOWmrlft2FI

p.s. Phil, I do hope you'll reconsider.

On Fri, Feb 5, 2016 at 10:47 PM Phil Steitz  wrote:

> OK, I give up.  I am withdrawing as volunteer chair or member of the
> new TLP.
>
> Phil
>
> On 2/5/16 7:23 PM, Gilles wrote:
> > Phil,
> >
> > You talk again about me trying to push forward changes that
> > serve no purpose besides "trash performance and correctness".
> > This is again baseless FUD to which I've already answered
> > (with detailed list of facts which you chose to ignore).
> > You declare anything for which you don't have an answer as
> > "bogus argument". Why is the reference to multi-threaded
> > implementations bogus?  You contradict yourself in pretending
> > that CM RNGs could be so good as to make people want to use
> > them while refusing to consider whether another design might
> > be better suited to such high(er)-performance extensions.
> > This particular case is a long shot but if any and all
> > discussions are stopped dead, how do you imagine that we can
> > go anywhere?
> > As you could read from experts, micro-benchmarks are deceiving;
> > but you refuse to even consider alternative designs if there
> > might be a slight suspicion of degradation.
> > How can we ever set up a constructive discussion on how to
> > make everybody enjoy this project if the purported chair is
> > so bent to protecting existing code rather than nurture a good
> > relationship with developers who may sometimes have other ideas?
> > I'm trying to improve the code (in a dimension which you can't
> > seem to understand unfortunately) but respectfully request
> > data points from those users of said code, in order to be
> > able to prove that no harm will be done.
> > But you seem to prefer to not disclose anything that would
> > get us closer to agreement (better design with similar
> > performance and room for improvement, to be discussed
> > together as a real development team -- Not you requiring,
> > as a bad boss, that I bow to your standards for judging
> > usefulness).
> > This 1% which you throw at me, where does it come from?
> > What does 1% mean when the benchmark shows standard deviations
> > that vary from 4 to 26% in the "nextInt" case and from 3 to
> > 7% in the "nextGaussian" case?
> > This 1% looks meaningless without context; context is what I'm
> > asking in order to try and establish objectively whether
> > another design will have a measurable impact on actual tasks.
> > I'm not going to show any "damaged" benchmark because of how
> > unwelcome you make me feel every time I wish to talk about
> > other aspects of the code.
> > There is no development community here.  Only solitary
> > coders who share a repository.
> >
> > Not sorry for the top-post,
> > Gilles
> >
> >
> > On Fri, 5 Feb 2016 17:07:16 -0700, Phil Steitz wrote:
> >> On 2/5/16 12:59 PM, Gilles wrote:
> >>> On Fri, 5 Feb 2016 06:50:10 -0700, Phil Steitz wrote:
>  On 2/4/16 3:59 PM, Gilles wrote:
> > Hi.
> >
> > Here is a micro-benchmark report (performed with
> > "PerfTestUtils"):
> > -
> > nextInt() (calls per timed block: 200, timed blocks: 100,
> > time
> > unit: ms)
> > name time/call std dev total time ratio
> > cv difference
> > o.a.c.m.r.JDKRandomGenerator 1.088e-05 2.8e-06 2.1761e+03 1.000
> > 0.26 0.e+00
> >o.a.c.m.r.MersenneTwister 1.024e-05 1.5e-06 2.0471e+03 0.941
> > 0.15 -1.2900e+02
> >   o.a.c.m.r.Well512a 1.193e-05 4.4e-07 2.3864e+03 1.097
> > 0.04 2.1032e+02
> >  o.a.c.m.r.Well1024a 1.348e-05 1.9e-06 2.6955e+03 1.239
> > 0.14 5.1945e+02
> > o.a.c.m.r.Well19937a 1.495e-05 2.1e-06 2.9906e+03 1.374
> > 0.14 8.1451e+02
> > o.a.c.m.r.Well19937c 1.577e-05 8.8e-07 3.1542e+03 1.450
> > 0.06 9.7816e+02
> > o.a.c.m.r.Well44497a 1.918e-05 1.4e-06 3.8363e+03 1.763
> > 0.08 1.6602e+03
> > o.a.c.m.r.Well44497b 1.953e-05 2.8e-06 3.9062e+03 1.795
> > 0.14 1.7301e+03
> >o.a.c.m.r.ISAACRandom 1.169e-05 1.9e-06 2.3375e+03 1.074
> > 0.16 1.6139e+02
> > -
> > where "cv" is the ratio of the 3rd to the 2nd column.
> >
> > Questions are:
> > * How meaningful are micro-benchmarks when the timed operation
> > has
> > a very
> >   small duration (wrt e.g. the duration of other machine
> > instructions that
> >   are required to perform them)?
> 
>  It is harder to get good benchmarks for shorter duration
>  activities,
>  but not impossible.  One thing that it would be good to do is to
>  compare these results with JMH [1].
> >>>
> >>> I was expecting insights based 

Re: [Math] How fast is fast enough?

[James Carman]

Passion is a good thing. It means he gives a damn. Gilles obviously cares
quite a bit about the subject matter. I think it's great that he's willing
to crack open some code that a lot of folks wouldn't touch and propose some
interesting changes. Perhaps adding the new implementations alongside the
existing ones would make sense? Maybe in a "beta" package? That way we can
get this stuff in front of folks and let them take it for a spin. Maybe we
create another artifact that we release with less strenuous rules around
backward compatibility? Just some thoughts.

On Fri, Feb 5, 2016 at 8:54 PM Niall Pemberton 
wrote:

> Are you not concerned about forming a TLP of 7 around Math when one of the
> seven is clearly not a happy camper?
>
> Niall
>
> On Sat, Feb 6, 2016 at 12:07 AM, Phil Steitz 
> wrote:
>
> > On 2/5/16 12:59 PM, Gilles wrote:
> > > On Fri, 5 Feb 2016 06:50:10 -0700, Phil Steitz wrote:
> > >> On 2/4/16 3:59 PM, Gilles wrote:
> > >>> Hi.
> > >>>
> > >>> Here is a micro-benchmark report (performed with "PerfTestUtils"):
> > >>> -
> > >>> nextInt() (calls per timed block: 200, timed blocks: 100, time
> > >>> unit: ms)
> > >>> name time/call std dev total time ratio
> > >>> cv difference
> > >>> o.a.c.m.r.JDKRandomGenerator 1.088e-05 2.8e-06 2.1761e+03 1.000
> > >>> 0.26 0.e+00
> > >>>o.a.c.m.r.MersenneTwister 1.024e-05 1.5e-06 2.0471e+03 0.941
> > >>> 0.15 -1.2900e+02
> > >>>   o.a.c.m.r.Well512a 1.193e-05 4.4e-07 2.3864e+03 1.097
> > >>> 0.04 2.1032e+02
> > >>>  o.a.c.m.r.Well1024a 1.348e-05 1.9e-06 2.6955e+03 1.239
> > >>> 0.14 5.1945e+02
> > >>> o.a.c.m.r.Well19937a 1.495e-05 2.1e-06 2.9906e+03 1.374
> > >>> 0.14 8.1451e+02
> > >>> o.a.c.m.r.Well19937c 1.577e-05 8.8e-07 3.1542e+03 1.450
> > >>> 0.06 9.7816e+02
> > >>> o.a.c.m.r.Well44497a 1.918e-05 1.4e-06 3.8363e+03 1.763
> > >>> 0.08 1.6602e+03
> > >>> o.a.c.m.r.Well44497b 1.953e-05 2.8e-06 3.9062e+03 1.795
> > >>> 0.14 1.7301e+03
> > >>>o.a.c.m.r.ISAACRandom 1.169e-05 1.9e-06 2.3375e+03 1.074
> > >>> 0.16 1.6139e+02
> > >>> -
> > >>> where "cv" is the ratio of the 3rd to the 2nd column.
> > >>>
> > >>> Questions are:
> > >>> * How meaningful are micro-benchmarks when the timed operation has
> > >>> a very
> > >>>   small duration (wrt e.g. the duration of other machine
> > >>> instructions that
> > >>>   are required to perform them)?
> > >>
> > >> It is harder to get good benchmarks for shorter duration activities,
> > >> but not impossible.  One thing that it would be good to do is to
> > >> compare these results with JMH [1].
> > >
> > > I was expecting insights based on the benchmark which I did run.
> >
> > You asked whether or not benchmarks are meaningful when the task
> > being benchmarked is short duration.  I answered that question.
> > >
> > > We have a tool in CM; if it's wrong, we should remove it.
> > > How its results compare with JMH is an interesting question,
> >
> > I will look into this.
> > > I
> > > agree, but I don't have time to make an analysis of benchmarking
> > > tools (on top of what I've been doing since December because
> > > totally innocuous changes in the RNG classes were frowned upon
> > > out of baseless fear).
> >
> > Please cut the hypberbole.
> > >
> > >>> * In a given environment (HW, OS, JVM), is there a lower limit
> > >>> (absolute
> > >>>   duration) below which anything will be deemed good enough?
> > >>
> > >> That depends completely on the application.
> > >
> > > Sorry, I thought that it was obvious: I don't speak of applications
> > > that don't care about performance. :-)
> > >
> > > For those that do, I do not agree with the statement: the question
> > > relates to finding a point below which it is the environment that
> > > overwhelms the other conditions.
> > > A point where there will be _unavoidable_ overhead (transferring data
> > > from/to memory, JVM book-keeping, ...) and perturbations (context
> > > switches, ...) such that their duration adds a constant time (on
> > > average) that may render most enhancements to an already efficient
> > > algorithm barely noticeable in practice.
> > > Similarly, but in the opposite direction, some language constructs
> > > or design choices might slow down things a bit, but without
> > > endangering any user.
> > >
> > > A problem arises when any enhancement to the design is deemed
> > > harmful because it degrades a micro-benchmark, even though that
> > > benchmark may not reflect any real use-cases.
> > > Then, the real harm is against development.
> > >
> > >>> * Can a library like CM admit a trade-off between ultimate
> > >>> performance and
> > >>>   good design?   IOW, is there an acceptable overhead in exchange
> > >>> for other qualities
> > >>>   (clarity, non-redundancy, extensibility, etc.)?
> > >>
> > >> That is too general a question to be meaningful.   We need to look
> > >> at specific 

Re: [RESULT] [math] Name of the new TLP

[James Carman]

Good question. I have proposed it many times in the past

On Mon, Feb 1, 2016 at 5:03 PM Gilles <gil...@harfang.homelinux.org> wrote:

> On Mon, 01 Feb 2016 15:05:57 +0000, James Carman wrote:
> > On Mon, Feb 1, 2016 at 9:50 AM Gilles <gil...@harfang.homelinux.org>
> > wrote:
> >
> >>
> >> "Math" is (a bit?) overwhelming for a team of 5- people.
> >>
> >> In "Commons" there was the rationale of accepting only "common"
> >> algorithms (although that was fairly fuzzy as a limitation).
> >> Not so with that overly general name.
> >> It's a library that will contain math, yes; all of math, certainly
> >> not.
> >> So the name is just a name; it should point to project, not to a
> >> general concept.
> >>
> >>
> > The TLP move for Apache Math will help it gain some visibility and
> > also
> > give it the ability to branch out to new areas.  There's nothing
> > saying
> > that the current 5 people are the only ones who will ever work on it.
> > The
> > idea is to grow the library.
>
> Having Math in Commons did not prevent anyone who wanted to join.
> If history of the last 10 years can be a guide, then there is nothing
> saying that candidates will suddenly become plenty.
> If it were obvious that the TLP move was the way to go to gain more
> visibility, then why did it take so long to do it? ;-)
>
> Gilles
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [math] [POLL] new TLP name

[James Carman]

For the record, I really do like epsilon also.

On Mon, Feb 1, 2016 at 12:14 PM James Carman <ja...@carmanconsulting.com>
wrote:

> Apache Math
>
> On Mon, Feb 1, 2016 at 12:06 PM Phil Steitz <phil.ste...@gmail.com> wrote:
>
>> Please select your top choice among the following suggested names
>> for the new [math]-based TLP.  All are welcome and encouraged to
>> respond.  This POLL will be open for 72 hours, at which time two
>> tallies will be presented:  one among those who have volunteered for
>> the new PMC and a second among all respondents.  Hopefully, one name
>> will emerge as consensus winner.  If not, I will kick off another
>> runoff poll among the top choices.   Please respond with your top
>> choice for the name.
>>
>> AjaMa
>> Epsilon
>> Erdos
>> Euclid
>> Euler
>> Gauss
>> JAML
>> Math
>> MathBlocks
>> MathComponents (or Math Components)
>> Mathelactica
>> MathModules
>> Megginson
>> modMath
>> Nash
>> Newton
>> Pythagoras
>>
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>

Re: [math] [POLL] new TLP name

[James Carman]

Apache Math

On Mon, Feb 1, 2016 at 12:06 PM Phil Steitz  wrote:

> Please select your top choice among the following suggested names
> for the new [math]-based TLP.  All are welcome and encouraged to
> respond.  This POLL will be open for 72 hours, at which time two
> tallies will be presented:  one among those who have volunteered for
> the new PMC and a second among all respondents.  Hopefully, one name
> will emerge as consensus winner.  If not, I will kick off another
> runoff poll among the top choices.   Please respond with your top
> choice for the name.
>
> AjaMa
> Epsilon
> Erdos
> Euclid
> Euler
> Gauss
> JAML
> Math
> MathBlocks
> MathComponents (or Math Components)
> Mathelactica
> MathModules
> Megginson
> modMath
> Nash
> Newton
> Pythagoras
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [RESULT] [math] Name of the new TLP

[James Carman]

On Mon, Feb 1, 2016 at 9:50 AM Gilles  wrote:

>
> "Math" is (a bit?) overwhelming for a team of 5- people.
>
> In "Commons" there was the rationale of accepting only "common"
> algorithms (although that was fairly fuzzy as a limitation).
> Not so with that overly general name.
> It's a library that will contain math, yes; all of math, certainly
> not.
> So the name is just a name; it should point to project, not to a
> general concept.
>
>
The TLP move for Apache Math will help it gain some visibility and also
give it the ability to branch out to new areas.  There's nothing saying
that the current 5 people are the only ones who will ever work on it.  The
idea is to grow the library.

Re: [math] Name of the new TLP

[James Carman]

Epsilon is catchy
On Mon, Jan 25, 2016 at 6:41 AM sebb <seb...@gmail.com> wrote:

> On 25 January 2016 at 09:28, luc <l...@spaceroots.org> 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 <ole.er...@gmail.com>:
> >>
> >>> 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 <gil...@harfang.homelinux.org>
> >>>> 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
> >>>

Re: [math] Name of the new TLP

[James Carman]

I googled that but didn't find anything compelling. I love the idea.

On Sun, Jan 24, 2016 at 4:54 PM Hasan Diwan <hasan.di...@gmail.com> wrote:

> If we are to choose a famous person's name, why not a famous native
> American mathematician? I'm not aware of any, but it would be keeping with
> the traditions of Apache, being a native American tribe, Geronimo being a
> native American chief, as well as a few others. -- H
>
> On 24 January 2016 at 13:51, Gary Gregory <garydgreg...@gmail.com> wrote:
>
> > On Jan 24, 2016 1:46 PM, "Phil Steitz" <phil.ste...@gmail.com> 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.
> >
> > +1
> >
> > Cute names end up being a hindrance IMO. How much clearer is "Apache
> > Commmons Imaging" that Sanselan (which I was never sure how to spell)?
> >
> > Gary
> >
> > >
> > > 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 <phil.ste...@gmail.com>
> > 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
> > >
> >
>
>
>
> --
> OpenPGP: https://hasan.d8u.us/gpg.key
> Sent from my mobile device
> Envoyé de mon portable
>

Re: [math] Name of the new TLP

[James Carman]

I'm okay with that too. Apache Math

On Sun, Jan 24, 2016 at 5:17 PM Gilles <gil...@harfang.homelinux.org> wrote:

> Just plain and simple "Apache Math" maybe?
> Or is it taken already?
>
> 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 <phil.ste...@gmail.com>
> >> 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

[James Carman]

I guess it depends on the scope of what the new TLP is going to do.
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
>
>