Re: Proposal Commons-JNDI

[Henri Yandell]

Stunned (and impressed) that there are users :) Haven't touched that in ages.

Would love to see Commons replace it. I'm slowly getting time again
for Apache, so would be happy to be involved. It's the major
genjava/osjava component that hasn't already been gutted and sent to
Commons.

Hen

On Wed, Aug 8, 2012 at 11:46 PM, Felix Meschberger  wrote:
> Hi,
>
> As a user of Simple JNDI I am  all for having a simple JNDI implementation in 
> ASF.
>
> +1 (non-binding) from me.
>
> Regards
> Felix
>
> Am 08.08.2012 um 08:02 schrieb Jochen Wiedmann:
>
>> Hi,
>>
>> I'd like to propose a new component Commons JNDI for the sandbox.
>>
>> The aim would be to have a very lightweight JNDI implementation (no
>> server, or something like that) that's not necessarily suitable for
>> production, but ideally suited for use in test suites, and the like.
>> For example, commons dbcp might use this to verify configuration via
>> JNDI. The new implementation ought to be driven by property, XML, or
>> JSON files.
>> Possible starting points:
>>
>> - Import Simple JNDI, which already comes very close to the target.
>> Henri Yandell, one of the Simple JNDI authors has given his agreement.
>> - Import Tomcat JNDI, no contact with the Tomcat developers exists on
>> that topic.
>>
>>
>> WDYT?
>>
>> Jochen
>>
>> --
>> In other words: what could be seen as a socially debilitating failure
>> of character can certainly work to your advantage too. (Linus
>> Torvalds, but the use in the signature tells something about me as
>> well.)
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: commons-lang pull request: Update src/main/java/org/apache/commons/lang3/Sy...

[Henri Yandell]

Cool to have a patch come in via github. Bear in mind there's nothing
to suggest Olloth is on the mailing list.

Hen

On Sat, Sep 1, 2012 at 6:16 PM, James Carman  wrote:
> Can you submit a JIRA and attach a SVN patch please?
>
> On Sat, Sep 1, 2012 at 8:19 PM, Olloth  wrote:
>> GitHub user Olloth opened a pull request:
>>
>> https://github.com/apache/commons-lang/pull/2
>>
>> Update src/main/java/org/apache/commons/lang3/SystemUtils.java
>>
>> Updated SystemUtils to account for Windows 8.
>>
>> Windows 8 RTM is released, soon to be going out to consumers. Many 
>> people are already using it.
>>
>> The current version is 6.2.9200.16384 (RTM) and the string returned by 
>> the java property is "Windows 8" in accordance with 7 and other versions.
>>
>> You can merge this pull request into a Git repository by running:
>>
>> $ git pull https://github.com/Olloth/commons-lang patch-1
>>
>> Alternatively you can review and apply these changes as the patch at:
>>
>> https://github.com/apache/commons-lang/pull/2.patch
>>
>> 
>> commit f39454442d3baee7ff7473d9251bbf13f1a0113a
>> Author: Dalton J Pelc 
>> Date:   2012-09-01T17:17:24-07:00
>>
>> Update src/main/java/org/apache/commons/lang3/SystemUtils.java
>>
>> Updated SystemUtils to account for Windows 8.
>>
>> 
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: commons-lang pull request: Update src/main/java/org/apache/commons/lang3/Sy...

[Henri Yandell]

Both on the first question :) Not me on the second.

On Mon, Sep 3, 2012 at 4:11 AM, James Carman  wrote:
> "Cool" as in "that's great that we're getting contributions from folks
> via Github" or "cool" as in "it's cool to use patches via Github pull
> requests, since there's an implied license grant"?
>
> I agree that it's minor enough that any of us could just implement it
> "from scratch" and just not worry.  Do any of us have a dev
> environment set up on a windows 8 machine (or VM I guess) yet?
>
> On Mon, Sep 3, 2012 at 5:01 AM, Henri Yandell  wrote:
>> Cool to have a patch come in via github. Bear in mind there's nothing
>> to suggest Olloth is on the mailing list.
>>
>> Hen
>>
>> On Sat, Sep 1, 2012 at 6:16 PM, James Carman  
>> wrote:
>>> Can you submit a JIRA and attach a SVN patch please?
>>>
>>> On Sat, Sep 1, 2012 at 8:19 PM, Olloth  wrote:
>>>> GitHub user Olloth opened a pull request:
>>>>
>>>> https://github.com/apache/commons-lang/pull/2
>>>>
>>>> Update src/main/java/org/apache/commons/lang3/SystemUtils.java
>>>>
>>>> Updated SystemUtils to account for Windows 8.
>>>>
>>>> Windows 8 RTM is released, soon to be going out to consumers. Many 
>>>> people are already using it.
>>>>
>>>> The current version is 6.2.9200.16384 (RTM) and the string returned by 
>>>> the java property is "Windows 8" in accordance with 7 and other versions.
>>>>
>>>> You can merge this pull request into a Git repository by running:
>>>>
>>>> $ git pull https://github.com/Olloth/commons-lang patch-1
>>>>
>>>> Alternatively you can review and apply these changes as the patch at:
>>>>
>>>> https://github.com/apache/commons-lang/pull/2.patch
>>>>
>>>> 
>>>> commit f39454442d3baee7ff7473d9251bbf13f1a0113a
>>>> Author: Dalton J Pelc 
>>>> Date:   2012-09-01T17:17:24-07:00
>>>>
>>>> Update src/main/java/org/apache/commons/lang3/SystemUtils.java
>>>>
>>>> Updated SystemUtils to account for Windows 8.
>>>>
>>>> 
>>>>
>>>>
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: Contributions to Commons Net and Codec

[Henri Yandell]

Looks like the CODEC-158 issue has already attracted requests for the patches :)

Hen

On Thu, Sep 27, 2012 at 2:23 PM, Mirko Raner  wrote:
> Hi there,
>
> I recently added some minor requests for improvements to the Net and Codec
> subprojects (NET-481 and CODEC-158). I actually have solutions for both
> problems that I'd like to contribute back to Apache Commons.
> If there is interest in incorporating those improvements into the code
> base, please respond on the particular issue and I'll be happy to submit a
> patch.
>
> Thanks,
>
> Mirko

-
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 Lang to git

[Henri Yandell]

+1.

On Sat, Jan 3, 2015 at 4:28 AM, Benedikt Ritter  wrote:

> Hi all,
>
> since we made first (good?) experiences with Commons Math using git as
> primary VCS, I'd like to call a vote to migrate Commons Lang to git.
>
> This vote by lazy consensus will close no sooner than 72 hours from now,
> i.e. after 2014/01/06 13:30 CET.
>
> Thanks,
> Benedikt
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>

Re: how to refine programming skill

[Henri Yandell]

As one idea, I would (if I didn't have too many demands on my time):

1) Browse through the APIs/Code for a piece of code that intrigues you.
2) Read it, write a blog on it, tweet about your blog (or whatever other
social networks you're into).
3) Learn about Caliper (https://github.com/google/caliper)
4) Write a Benchmark for that piece of code. Blog about doing that,
explaining how you did it.
5) Consider whether you can optimize the code and use Caliper to make your
case.
6) Goto #1.

Hen


On Fri, Jul 10, 2015 at 10:56 AM, Phil Steitz  wrote:

> On 7/10/15 4:35 AM, Daniel C. S. Yeh wrote:
> > Dear all,
> >
> > I am newer here. I want to involve in open source project development.
> >
> > By this way, I can see the good software architecture and bugs fixing
> > practice.
> >
> > could anyone kind tell me how to do it step by step, slowly?
>
> Siegfried did a great job describing how to get involved.   One
> thing that he mentioned that worked for me when I first started is
> working on unit tests and documentation.  The great thing about OSS
> is that most projects have a lot of unit tests and you can use them
> to understand how the code works and how small changes affect it.
> For Commons components, sometimes our javadoc is not as clear as it
> could be.  Unit tests can confirm exact behavior and javadoc can be
> improved.  I remember when I first started working on [lang], that's
> how I started - asking on the mailing list what exactly was meant by
> some vague javadoc, then confirming with unit tests and also
> improving the javadoc.  I got to learn and the tests and javadoc
> were improved.  Adding unit tests to open bug reports is also a
> great service and a good way to get into the code.
>
> Don't be bashful to ask questions about how the code works or how to
> get set up.  Sometimes it may take a while to get a response because
> we have a lot of components and some don't have many active
> contributors; but we welcome questions about the code and documentation.
>
> Welcome to Commons!
>
> Phil
>
>
> >
> > Many thanks
> > Daniel
> >
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [lang] running tests in eclipse

[Henri Yandell]

Try this one:

https://issues.apache.org/jira/browse/LANG-1143

Sebb's already broken the back on it and I laid out the remaining work.

If you've not hit codepoints before, they're quite an interesting area to
dive into. You don't need to dive into it much, but reading up on them so
you understand why the issue exists is good.

Hen

On Sat, Aug 1, 2015 at 9:51 AM, Daniel C. S. Yeh 
wrote:

> but how to decide which one is easy?
>
>
>
> On Sun, Aug 2, 2015 at 12:40 AM, Pascal Schumacher <
> pascalschumac...@gmx.net
> > wrote:
>
> > You are welcome. :)
> >
> > I guess fixing an easy bug is a good way to start. :)
> >
> >
> > Am 01.08.2015 um 17:57 schrieb Daniel C. S. Yeh:
> >
> >> thanks so much
> >> it can work right now
> >> how will you suggest me for the next step?
> >> try to fix a bug?
> >>
> >> On Sat, Aug 1, 2015 at 9:55 PM, Pascal Schumacher <
> >> pascalschumac...@gmx.net>
> >> wrote:
> >>
> >> These are "normal", you should be able to import the project and run the
> >>> test anyway. You can also choose "Mark target as ignored in Eclipse" or
> >>> something similar on the screen under "Action".
> >>>
> >>>
> >>> Am 01.08.2015 um 15:51 schrieb Daniel C. S. Yeh:
> >>>
> >>>
> 
> https://drive.google.com/open?id=0B5vA4_rneQA7Ry04QnRJLXdmREkybnB1Nk1EZG9ab2Q5R19z
> 
> 
>  On Sat, Aug 1, 2015 at 9:48 PM, Pascal Schumacher <
>  pascalschumac...@gmx.net>
>  wrote:
> 
>  Sorry, the picture got lost.
> 
> > I guess the mailing list does not allow pictures.
> >
> > Am 01.08.2015 um 15:24 schrieb Daniel C. S. Yeh:
> >
> > thanks
> >
> >> but i encountered  this problem
> >>
> >> Inline image 1
> >>
> >>
> >> On Sat, Aug 1, 2015 at 8:40 PM, Pascal Schumacher <
> >> pascalschumac...@gmx.net > wrote:
> >>
> >>   Hi Daniel,
> >>
> >>   you need the M2Eclipse plugin: http://www.eclipse.org/m2e/
> >>
> >>   I thought that was bundled with Eclipse nowadays.
> >>
> >>   -Pascal
> >>
> >>   Am 01.08.2015 um 13:54 schrieb Daniel C. S. Yeh:
> >>
> >>   Hi Pascal,
> >>
> >>   I cannot find any import option called "existing maven
> >>   project" in my
> >>   eclipse.
> >>
> >>   Do I have to install anything?
> >>
> >>   Thanks
> >>   Daniel
> >>
> >>   On Sat, Aug 1, 2015 at 7:51 PM, Pascal Schumacher
> >>pascalschumac...@gmx.net
> >> >>
> >>   wrote:
> >>
> >>   Hi Daniel,
> >>
> >>   did you import commons-lang as an "existing maven
> >> project"
> >>   into eclipse?
> >>   That's the easiest way imho.
> >>
> >>   You should be able to run a test by right-clicking an
> >>   choosing "Run as" ->
> >>   "JUnit Test"
> >>
> >>   Cheers,
> >>   Pascal
> >>
> >>   Am 01.08.2015 um 13:32 schrieb Daniel C. S. Yeh:
> >>
> >>   Dear all,
> >>
> >>   I am a newer here. I downloaded the source code of
> >>   common lang 3 from git
> >>   server and imported them to eclipse.
> >>
> >>   I want to start everything from a bug fixing -
> >>
> >>
> >>
> >>
> >>
> https://issues.apache.org/jira/browse/LANG-1148?jql=project%20%3D%20LANG%20AND%20issuetype%20%3D%20Bug%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22)%20ORDER%20BY%20key%20DESC
> >>   <
> >>
> >>
> >>
> https://issues.apache.org/jira/browse/LANG-1148?jql=project%20%3D%20LANG%20AND%20issuetype%20%3D%20Bug%20AND%20status%20in%20%28Open%2C%20%22In%20Progress%22%29%20ORDER%20BY%20key%20DESC
> >>   .
> >>
> >>   In eclipse project explorer, I can find
> >>   StringUtilsTest in the folder
> >>   called test. However, I have no idea how to run
> it?
> >>
> >>   Does anyone know it?
> >>
> >>   Many thanks
> >>   Daniel
> >>
> >>
> >>
> >>
> >>   On Thu, Jul 30, 2015 at 11:04 AM, Phil Steitz
> >>>> phil.ste...@gmail.com>>
> >>
> >>   wrote:
> >>
> >>   Here is my +1
> >>
> >>   Phil
> >>
> >>   On 7/28/15 8:41 PM, Phil Steitz wrote:
> >>
> >>   I would like to cut another patch release
> to
> >>   pick up recent bug fixes.
> >>
> >>   This is a vote to release version 2.4.2 of
> >> Apache
> >>  

Re: need some help

[Henri Yandell]

The currently active projects is a good question (and as I'm not that
active myself, let's see which are active).

When we were all using Subversion it was easier, but now some components
are on Git and some Subversion.

Looks like four are on Git (Math, Lang, Compress and SCXML). I would
assume, based on recentness of the migrations, that all four are active.

For the rest, you can see their most recent activity by sorting by Age on
this SVN directory (the top 20 would imply _possibly_ active to me):

https://svn.apache.org/viewvc/commons/proper/?sortby=date#dirlist

And for the Sandbox:

https://svn.apache.org/viewvc/commons/sandbox/?sortby=date#dirlist

There only the one (inject) looks like it might be active.

Unless you use one of the projects, the next issue you hit is what to work
on.

Each has a JIRA project. You can find the list of them here:

https://issues.apache.org/jira/secure/BrowseProjects.jspa#10260

Click on a project, click issues, click View Issues and browse the open
issues. There will be many that are open ended, and some will be that way
because there's no real good solution, so early on the recommendation is to
look for issues that are concretely described.

For example - Sebb and I worked on this one:
https://issues.apache.org/jira/browse/LANG-1143 - I think it's a case of
finishing the work (we're both stretched all over the place) and might be a
good one to work on. IMO Lang does tend to have the more easily
approachable first items (but I'm biased :) ).

Contribution process can be via GitHub (
https://github.com/apache/commons-lang) or via attachments to a JIRA issue
(generated using svn diff or git diff).
https://commons.apache.org/patches.html has more about patches, common
sense stuff, but the type of thing you might not think about while heads
down on a first contribution.

Lastly - ask questions. One of the hardest habits to lose when getting into
Open Source (imo; and I'm making an assumption that those interested in
participating are often fairly new to open source teams) is that feeling
that a question will lead to shame. A question, especially one that
mentions the web page you looked at and didn't find an answer on, often
identifies a need for better documentation. Having asked the question, make
your next step a contribution to make it so the next person doesn't need to
ask.

To that end - https://commons.apache.org/site-publish.html appears to be
the documentation for getting the site. Use this JIRA for patches/issues in
the site: https://issues.apache.org/jira/browse/COMMONSSITE

Hope some of that helps :)

Hen


On Wed, Sep 2, 2015 at 8:10 AM, Arsen Babakhanyan 
wrote:

> Hi everybody,
> I am interested in participating in some projects, but need some help.
> I don't know how to find currently active projects that are in development
> or a project that needs help at all and the second problem help with
> getting started as i am new here. (going to be :) )
>

Re: Proposed Contribution to Apache Commons,

[Henri Yandell]

On Tue, Sep 29, 2015 at 5:42 PM, Phil Steitz  wrote:

> On 9/29/15 3:55 PM, Gary Gregory wrote:
> > Norman,
> >
> > Hello and welcome to Apache Commons.
> >
> > It's not clear to me why Naomi is better than regular expressions.
> Pointing
> > to Javadocs is not the best way to get traction.
> >
> > Your project would be better served by having some documentation on your
> > front page with an example driven tutorial.
> >
> > Is Naomi faster than REs?
> >
> > What can I do in Naomi that REs can't do? And vice-versa.
> >
> > Examples of this on your front page would help you at least get folks to
> > consider learning a brand new way of doing things...
>
> +1
> The code in SimpleExamples starts to get to this.  Looks interesting
> and powerful.  Either here or on the github readme you should take a
> stab at explaining a little more how hard problems using regex get
> easier with naomi, illustrated with some simple examples.  Then
> maybe with help from community members here, you can develop some
> overview / getting started docs that help people get into the code.
>

+1.

Reading SimpleExamples, my summary would be a boilerplate description of
"It replaces the arcane regular expression language with an API". It
reminds me of command line argument parsers. Perl had/has a great regular
expression like command line argument parser, but it was cryptic and you
either loved it or hated it. Then along came Commons CLI, args4j and all
the others, providing a more OO/procedural API instead of its own mini
language. Not as 'powerful' (in that you had to type more), but simpler (in
that you didn't have to learn a new lingo and didn't have to juggle
multiple languages inside one context (a source file)).

I definitely need that user manual. It's hard, with a brain trained on
regular expressions, to read 'Pattern greek3=new CharSequencePattern("?")'
and realize (I think) that it means a literal ? character. It's also the
primary way it'll be successful. You need that educational path that
explains what a ExplicitCharClass is for, rather than randomly clicking on
javadoc :)

There'll also be much debate to be had I suspect. Is "a-e" too complex,
compared to "abcde" or "a","e". Which parts of regex are worth supporting,
vs not. Can I mix bits of regexp with bits of Naomi?   new
ExplicitCharClass("a-eg-p").

Random I'd like the idea of varargs for automatic and'ing. ie:

new ExplicitCharClass("a-p", "!f")   [and is a not char class too complex?].

Continuing on my summary, as I peruse the code a little more, I'd go with:

"Build a regular expression via an API, not an arcane language of its own".

I'd love to see that grow to:

"Express regular expressions as objects, or mix and match objects with that
arcane mini language we all love or loathe".

Hen

Re: [VOTE] Accept Naomi

[Henri Yandell]

On Sat, Oct 31, 2015 at 2:49 PM, Phil Steitz  wrote:

> On 10/31/15 3:35 AM, Uwe Barthel wrote:
> > Hi Siegfried,
> >
> > Thanks for your clarification.
> >
> > It's really commonly use to bypass the incubator for small projects to
> become Apache Commons subproject status?
>
> Apache Commons is one project - we don't have subprojects.  We have
> accepted code grants directly before, sometimes into new components,
> sometimes merged in to existing components.  The key is as Mark
> pointed out whether or not we have interest already here in Commons
> in working on the code.  if that is the case, we can just accept the
> code grant and work with the community as we do on other components;
> otherwise it makes sense to try to grow community either in the
> Incubator or elsewhere before we accept the code.
>

Few add-on thoughts:

* The thread talks about growing community. Which community? The notion of
Commons is that a community develops/manages N components. None of our
components (or very few) support their own community. If we have enough +1
involvement (where +1 means 'will do coding, not just in favour'), then our
community seems fine.

* Emmanuel noted a preference for Commons components being refactored out
of other Apache projects. I want to note that early days of a lot of
Commons components were about code from people's personal libraries merging
in, not just Apache projects. Merging is an important word there though and
different to the notion of a full component coming in from outside.

* I see a lot of talking on list and not much engagement with Norm and Jeff
(either to or from them). This concerns me.

Hen

Re: Proposed fluent string utils

[Henri Yandell]

My suggestion would be to add a link to teh Commons Lang website to Micha's
repo and see how successful it is (i.e. if successful, I'd expect to see
users contributing other Lang related fluent APIs to it).

I'd suggest renaming to fluengLang :)

On Mon, Nov 16, 2015 at 11:50 AM, Benedikt Ritter 
wrote:

> Hello again,
>
> 2015-11-16 20:22 GMT+01:00 Micha Pringle :
>
> > Hi Benedikt,
> >
> > Thanks for the reply.
> >
> > I will update the current code and make the following changes, then
> notify
> > the mail list when it is complete for further review.
> > * Java 8 will be downgraded to Java 6. That's my own fault for unit
> > testing with lambda's.
> > * I would prefer to keep the annotations (especially the tiny
> > net.jcip:jcip-annotations:1.0), but I will drop them and replace with
> > javadoc.
> > * I intended this to go into commons-lang3, I will look at BeanUtils2 and
> > make the appropriate changes.
> > * Since this idea looks like it will be included in Apache Commons
> (lang3)
> > I will review Java String and Guava String API's, to make sure nothing is
> > missed (and add unit tests). That seems unlikely though, StringUtils
> seems
> > to cover all the bases.
> >
>
> I'm currently not convinced that this really belongs into Commons Lang.
> Lang's description is "The standard Java libraries fail to provide enough
> methods for manipulation of its core classes. Apache Commons Lang provides
> these extra methods.". My opinion is, that we already have stuff in Lang
> that isn't just auxiliary methods to the java.lang package. The change you
> propose looks like a fluent wrapper to java.lang.String, which while
> generally useful does not feel like it belongs into Commons Lang. That's
> why I've proposed to publish this as an additional package for
> commons-lang3.
>
> If you would like to join development of Commons Lang, you can simply go to
> the bug tracker [1] and look through the open issues. To start working on
> open source projects, it's good to find small things to fix first. This
> JavaDoc could be clearer, that test could be added, etc. This helps to get
> a general feeling for the library at hands, before tossing a big change
> over with no discussion. It is very important for ASF projects to find
> consensus in the community before changing code. So if you have an idea
> which sounds good at the beginning, it may not fit into the project you
> want to contribute it to. This doesn't make the idea less good, but it may
> lead to frustration if changes are not discussed at first.
>
> Having said this, I hope your not discouraged because I don't feel like
> your FluentWrapper belongs into commons. We need people like you who are
> enthusiastic! And by the way, I'm not the one to decide whether is will be
> added or not. I'm just sharing my thought. There may be other project
> members you think this fits. It is still open for discussion.
>
>
> >
> > Without having yet looked at BeanUtils2 (so this might be a moot
> > question), would it be useful to have a commons-lang3.fluent package or
> the
> > like?
> >
>
> I don't feel like "implementing fluent wrappers" is something that belongs
> into commons. There could be a commons-fluent component or something like
> that, which provides fluent wrappers for classes of the JDK. Given the
> popularity of fluent APIs, this may be something others could have a use of
> as well.
>
>
> >
> > As for unit testing, do you want me to test all the delegating methods as
> > well? It seems like a lot of work for nominal gain.
> >
>
> Changes should always be backed up by unit tests.
>
>
> >
> > Thanks again.
> >
>
> Thank you for your interest in Apache Commons.
>
> Benedikt
>
> [1] http://issues.apache.org/jira/browse/LANG
>
>
> >
> > Cheers,
> > Micha
> > --
> > *From:* Benedikt Ritter 
> > *To:* Commons Developers List ; Micha Pringle <
> > michaprin...@yahoo.com>
> > *Sent:* Monday, November 16, 2015 11:00 AM
> > *Subject:* Re: Proposed fluent string utils
> >
> > Hello Micha,
> >
> > 2015-11-15 1:47 GMT+01:00 Micha Pringle  >:
> >
> >
> > I really apologize, it seems the link below still managed to include a
> > period despite my best efforts. Please tryhttps://
> > github.com/michapringle/fluentStringUtils
> >
> > Cheers,Micha  From: Micha Pringle 
> >  To: "dev@commons.apache.org" 
> >  Sent: Saturday, November 14, 2015 4:44 PM
> >  Subject: Proposed fluent string utils
> >
> > Hi folks,
> >
> > Firstly, apologies if this results in a double post. I tried posting a
> > couple of times, but the first time I sent to the user list (sorry), and
> > the second time I do not see my email at all in the mail archive (
> > http://mail-archives.apache.org/mod_mbox/commons-dev/201511.mbox/thread
> ).
> > Hopefully 3rd time is the charm, and again, sorry for my n00biness.
> > I have written a fluent wrapper for the string utils class. Being new to
> > commit anything to Apache Commons, and given the nature of the change, I
> > wr

Re: [math] TLP

[Henri Yandell]

+1 (non-binding).

On Thu, Jan 14, 2016 at 1:59 PM, Siegfried Göschl <
siegfried.goes...@it20one.com> wrote:

> Hi folks,
>
> +1 for going TLP (non-binding)
>
> And the luck for Luc :-)
>
> Siegfried Goeschl
>
>
>
> - Ursprüngliche Mail -
> Von: "Luc Maisonobe" 
> An: "Commons Developers List" 
> Gesendet: Donnerstag, 14. Januar 2016 11:58:47
> Betreff: Re: [math] TLP
>
> Hi Phil,
>
> Le 14/01/2016 01:50, Phil Steitz a écrit :
> > I would like to propose that we split [math] out into a top level
> > project at the ASF.  This has been proposed before, and I have
> > always come down on the side of staying in Commons, but I am now
> > convinced that it is a good step for us to take for the following
> > reasons:
> >
> > 0) We have several committers who are really only interested in
> > [math], so being on the Commons PMC does not really make sense for them
> > 1) The code base has swollen in size to well beyond the "small sharp
> > tools" that make up the bulk of Commons
> > 2) 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 downsides are
> > a) [newPMC] loses Commons eyeballs / contributors who would not find
> > us otherwise
> > b) Migration / repackaging pain
> > c) Overhead of starting and managing a PMC
> > d) Other Commons components lose some eyeballs
> >
> > Personally, I think the benefits outweigh the downsides at this
> > point.  New better tools and ASF processes have made b) and c) a
> > little less onerous.  I don't think d) is really a big problem for
> > Commons, as those of us who work on other stuff here could continue
> > to do so.  It is possible that a) actually works in the reverse
> > direction - i.e., we are easier to find as a TLP.
> >
> > What do others think about this?
>
> I also think it is now time for us to grow up and leave parents home.
> [math] has become big, really big by now. It looks more like a
> standalone autonomous project than a shared component. Since a few
> years, it started to becomes a singular component, not really
> similar to the others. We almost monopolize the bandwidth on the
> mailing list, which can be painful for non-math developers.
>
> I think going TLP could also allow us to do somes things differently,
> perhaps experimenting on less stringent constraints about releases,
> mainly related to stuff that is not stabilized. We could also accept
> some ideas that were rejected up to now as not fitting in commons
> scope (higher level stuff like the expression parser that was submitted
> twice by different people if I remember well).
>
> So +1 for going TLP.
>
> best regards,
> Luc
>
> >
> > Phil
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VOTE] Form a separate TLP based on [math]

[Henri Yandell]

On Sat, Jan 16, 2016 at 7:18 AM, Phil Steitz  wrote:

> The discussion has thus far been generally favorable.  I would like
> therefore to put the proposal to split [math] out into a separate
> TLP to a VOTE.  Assuming a favorable vote, we can discuss how to go
> about doing it.  Votes, please.  All are welcome to vote.
>
> [ ] +1 I am in favor of this action
>

+1 (non-binding).

Hen

Re: [math] Name of the new TLP

[Henri Yandell]

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

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

Hen


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

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

[CLI] Enhancement ideas [Was: WELCOME to dev@commons.apache.org]

[Henri Yandell]

Changing the subject so Jay's email gets noticed.

Hen

On Wed, Dec 21, 2011 at 3:24 PM, Jay Vyas  wrote:
> Hi guys : I wanted to add some features to CLI
>
> 1) Options iterators , make them generic
> 2) Add an option for setting ALL options to mandatory.
> 3) Add an option to add groups, using the addOption api, the same way we
> add options.
>
> In any case - would such contirbutions be welcome.. and if so - who would i
> push commits to ?

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

[lang] 3.3?

[Henri Yandell]

Heads up that I'm thinking that 3.3 is ready to be released. 10 issues
resolved in trunk.

Hen

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

Re: [lang] 3.2?

[Henri Yandell]

Of course, I mean 3.2. :)

On Tue, Dec 27, 2011 at 11:46 PM, Henri Yandell  wrote:
> Heads up that I'm thinking that 3.3 is ready to be released. 10 issues
> resolved in trunk.
>
> Hen

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

Re: [lang] 3.2?

[Henri Yandell]

Three changes of interest. Two are the removal of final on public
methods. The other is the addition of Serializable to StrBuilder.

Which is the worry? And is it a big enough worry to not keep the change?

Hen

On Wed, Dec 28, 2011 at 6:07 AM, Gary Gregory  wrote:
> Fire it up! :)
>
> Despite what Clirr reports, are the changes really binary compatible?
>
> Gary
>
> On Wed, Dec 28, 2011 at 2:48 AM, Henri Yandell  wrote:
>
>> Of course, I mean 3.2. :)
>>
>> On Tue, Dec 27, 2011 at 11:46 PM, Henri Yandell 
>> wrote:
>> > Heads up that I'm thinking that 3.3 is ready to be released. 10 issues
>> > resolved in trunk.
>> >
>> > Hen
>>
>> -
>> 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
> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

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

Re: [math] Compatibility of licenses?

[Henri Yandell]

2012/1/11 Sébastien Brisard :
> Le 11 janvier 2012 07:42, Sébastien Brisard
>  a écrit :
>> Hi,
>> Dennis recently contributed a patch for triangular distributions (see
>> MATH-731). One of the methods implemented is based on a third party
>> Python code, the license of which is reproduced below. My question is:
>> can I commit this patch? Should we try and get in touch with the
>> original author (1998!), to have him sign an ICLA?
>> Thanks for your advice.
>> Sébastien
>>
>> + * Implementation of the {@link #sample} method partly based on 
>> triangular
>> + * distribution implementation of the rv Python module (Release 1.1 
>> 27-Nov-98),
>> + * by Ivan Frohne, which is distributed under the following license:
>> + * 
>> + *            Copyright 1998 by Ivan Frohne; Wasilla, Alaska, U.S.A.
>> + *                        All Rights Reserved
>> + *
>> + * Permission to use, copy, modify and distribute this software and its
>> + * documentation for any purpose, free of charge, is granted subject to the
>> + * following conditions:
>> + *   The above copyright notice and this permission notice shall be 
>> included in
>> + *   all copies or substantial portions of the software.
>> + *
>> + *   THE SOFTWARE AND DOCUMENTATION IS PROVIDED WITHOUT WARRANTY OF ANY 
>> KIND,
>> + *   EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO MERCHANTABILITY, 
>> FITNESS
>> + *   FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL THE
>> + *   AUTHOR OR COPYRIGHT HOLDER BE LIABLE FOR ANY CLAIM OR DAMAGES IN A
>> + *   CONTRACT ACTION, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN 
>> CONNECTION
>> + *   WITH THE SOFTWARE OR ITS DOCUMENTATION.
>> + * 
>> + * 
>
> This is the answer I got on legal-disc...@apache.org
> {quote}
> t might also be an option for the commons PMC to personally reach out
> to him, notify him and send him a personal 'thank you'. Maybe he is
> even interested to help out in other areas as committer in the future
> ;)
> {quote}
>
> Any PMC willing to contact this guy (Ivan Frohne) personally?
> Otherwise, I can take care of that.
> Sébastien

"Hi, about this Python code you wrote 14 years ago" :)

Highly unlikely he's jumping at the bit to code in Commons Math.
Still, sending a thanks is polite and I'd recommend you doing it as it
always sounds best coming from the person closest to the commit.

Hen

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

Re: [DBUTILS] Few unit tests for BeanProcessor; none for SQLXML support

[Henri Yandell]

Tell me why 1.6 is a problem again?

This is DB-helper code, so much less worried about use cases like Android.

Hen

On Fri, Jan 6, 2012 at 3:05 AM, sebb  wrote:
> I did some experimenting with BeanProcessor to see what would be
> involved in providing Java 1.5 support.
>
> As part of this, I tried commenting out the new code that requires Java 1.6.
>
> All tests still worked.
>
> I then commented out most of the rest of the else if clauses in the
> processColumn method, and the unit tests still worked.
>
> I think it might be fairly easy to recode the SQLXML section so it
> still works in Java 1.5, but without a proper unit test, this is
> difficult to prove.
>
> In any case, more unit tests are definitely needed.
>
> -
> 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: When to create a new major release - Was [VOTE][CANCEL] The vote for commons-email-1.3 based on RC2 in cancelled

[Henri Yandell]

On Tue, Jan 10, 2012 at 10:19 AM, sebb  wrote:
> On 10 January 2012 16:45, Siegfried Goeschl  wrote:
>> Hi folks,
>>
>> the main reason for the failed vote of commons-email-1.3 is that the release
>> is only source but not binary compatible
>>
>> +) if you compile your application with the new version everything is fine
>> +) if you replace simply the JAR the invocation fails
>>
>> Is it mandatory that a minor release is binary compatible with the previous
>> one or do I have to create a new major version? There is a lot of ugly stuff
>> (mainly protected member variables) which should be done but is currently
>> not in the scope of this release.
>
> If the jar is not a drop-in replacement for the previous version, then
> yes, IMO that requires a major release. [1]
> The only possible exception might be if the incompatibilities are in
> internal parts of the API, i.e. classes/methods etc. that are not used
> externally.

Thinking back on previous discussions, the primary exception has been
the API itself is the bug and needs changing.

A contrived (and over-simple) example would be:

public void toUppercase(String s);

It'd be better to fix the return type than live with bad API.

Rare, but worth mentioning I thought.

Hen

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

Re: [ALL] Supported Buildsystems of each component

[Henri Yandell]

Couldn't we generate this?

It feels like a very simple svn script to see if a component has a
build.xml, pom.xml or project.xml.

Hen

On Sun, Jan 8, 2012 at 4:50 AM, Christian Grobmeier  wrote:
> Hello,
>
> we have a nice wikipage mentioning what buildsystem is supported for
> which component:
> http://wiki.apache.org/commons/BuildSystems
>
> Can everybody update the lines for the components he is caring about?
> For components which do not support maven3 just add a "no" in the
> column - this way we know which lines have been updated.
>
> Cheers,
> Christian
>
> -
> 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] Compatibility of licenses?

[Henri Yandell]

2012/1/12 Sébastien Brisard :
> Hi Henri
>>
>> "Hi, about this Python code you wrote 14 years ago" :)
>>
> :))
>
>>
>> Highly unlikely he's jumping at the bit to code in Commons Math.
>> Still, sending a thanks is polite and I'd recommend you doing it as it
>> always sounds best coming from the person closest to the commit.
>>
> That's how I felt about it, but I certainly do not want to act "above
> my rank". Thanks for this advice, I'll remember about it next time I
> come across this issue.

With the exception of the PMC Chair, where pulling rank is a
last-ditch option and should be avoided, and the PMC for the binding
vote, where ignoring a -1 from non-PMC would be a very bad sign, every
committer has the same 'rank'.

Some of us have lots of outdated anecdotes that may educate, inspire
or more likely simply bore, but that's it. :)

Hen

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

Re: [DBUTILS] Few unit tests for BeanProcessor; none for SQLXML support

[Henri Yandell]

Oracle declared 1.5 EOL a good while back; ie) no security fixes; why
should we encourage users to be on outdated versions?

Especially as I think there are pretty big security issues unfixed in
1.5 (the magic floating number crash for example). If you're still on
1.5, you have worse problems than pieces of Commons throwing a
ClassNotFound.

I'm tempted to go as far as to say it's irresponsible of us to support 1.5 :)

Hen

On Thu, Jan 12, 2012 at 2:55 AM, sebb  wrote:
> On 12 January 2012 08:20, Henri Yandell  wrote:
>> Tell me why 1.6 is a problem again?
>
> Because there are likely to be many companies still using Java 1.5 out there.
>
> I was hoping to fix the code so they are not prevented from using the
> new version.
>
>> This is DB-helper code, so much less worried about use cases like Android.
>>
>> Hen
>>
>> On Fri, Jan 6, 2012 at 3:05 AM, sebb  wrote:
>>> I did some experimenting with BeanProcessor to see what would be
>>> involved in providing Java 1.5 support.
>>>
>>> As part of this, I tried commenting out the new code that requires Java 1.6.
>>>
>>> All tests still worked.
>>>
>>> I then commented out most of the rest of the else if clauses in the
>>> processColumn method, and the unit tests still worked.
>>>
>>> I think it might be fairly easy to recode the SQLXML section so it
>>> still works in Java 1.5, but without a proper unit test, this is
>>> difficult to prove.
>>>
>>> In any case, more unit tests are definitely needed.
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [ALL] Supported Buildsystems of each component

[Henri Yandell]

On Thu, Jan 12, 2012 at 2:56 AM, sebb  wrote:
> On 12 January 2012 08:28, Henri Yandell  wrote:
>> Couldn't we generate this?
>>
>> It feels like a very simple svn script to see if a component has a
>> build.xml, pom.xml or project.xml.
>
> But that won't detect if the scripts actually still work.

Agreed, but neither will the wiki. Unlike the wiki, it will detect
when the build is removed.

Not that I know how to integrate it into the website, but 'seems easy' :)

Hen

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

Re: When to create a new major release - Was [VOTE][CANCEL] The vote for commons-email-1.3 based on RC2 in cancelled

[Henri Yandell]

On Thu, Jan 12, 2012 at 2:52 AM, sebb  wrote:
> On 12 January 2012 08:27, Henri Yandell  wrote:
>> On Tue, Jan 10, 2012 at 10:19 AM, sebb  wrote:
>>> On 10 January 2012 16:45, Siegfried Goeschl  wrote:
>>>> Hi folks,
>>>>
>>>> the main reason for the failed vote of commons-email-1.3 is that the 
>>>> release
>>>> is only source but not binary compatible
>>>>
>>>> +) if you compile your application with the new version everything is fine
>>>> +) if you replace simply the JAR the invocation fails
>>>>
>>>> Is it mandatory that a minor release is binary compatible with the previous
>>>> one or do I have to create a new major version? There is a lot of ugly 
>>>> stuff
>>>> (mainly protected member variables) which should be done but is currently
>>>> not in the scope of this release.
>>>
>>> If the jar is not a drop-in replacement for the previous version, then
>>> yes, IMO that requires a major release. [1]
>>> The only possible exception might be if the incompatibilities are in
>>> internal parts of the API, i.e. classes/methods etc. that are not used
>>> externally.
>>
>> Thinking back on previous discussions, the primary exception has been
>> the API itself is the bug and needs changing.
>>
>> A contrived (and over-simple) example would be:
>>
>>    public void toUppercase(String s);
>>
>> It'd be better to fix the return type than live with bad API.
>>
>> Rare, but worth mentioning I thought.
>
> But that can still cause jar hell.
>
> If there are multiple jars in the same classloader that use the broken
> API, they will all have to be updated at the same time.
> May be tricky or impossible even if they are not from different providers.
>
> That's why binary compatibility is so important.

Bad packaging practices causes jar hell. There's only so far we can go
worrying about how our code is used.

Part of the reason I felt it worth mentioning is that binary
compatibility is not a magic trump card that aces everything else.
It's very strongly desirable but not a mandatory absolute.

Hen

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

Re: When to create a new major release - Was [VOTE][CANCEL] The vote for commons-email-1.3 based on RC2 in cancelled

[Henri Yandell]

On Fri, Jan 13, 2012 at 5:09 AM, sebb  wrote:
> On 13 January 2012 06:00, Henri Yandell  wrote:
>> On Thu, Jan 12, 2012 at 2:52 AM, sebb  wrote:
>>> On 12 January 2012 08:27, Henri Yandell  wrote:
>>>> On Tue, Jan 10, 2012 at 10:19 AM, sebb  wrote:
>>>>> On 10 January 2012 16:45, Siegfried Goeschl  wrote:
>>>>>> Hi folks,
>>>>>>
>>>>>> the main reason for the failed vote of commons-email-1.3 is that the 
>>>>>> release
>>>>>> is only source but not binary compatible
>>>>>>
>>>>>> +) if you compile your application with the new version everything is 
>>>>>> fine
>>>>>> +) if you replace simply the JAR the invocation fails
>>>>>>
>>>>>> Is it mandatory that a minor release is binary compatible with the 
>>>>>> previous
>>>>>> one or do I have to create a new major version? There is a lot of ugly 
>>>>>> stuff
>>>>>> (mainly protected member variables) which should be done but is currently
>>>>>> not in the scope of this release.
>>>>>
>>>>> If the jar is not a drop-in replacement for the previous version, then
>>>>> yes, IMO that requires a major release. [1]
>>>>> The only possible exception might be if the incompatibilities are in
>>>>> internal parts of the API, i.e. classes/methods etc. that are not used
>>>>> externally.
>>>>
>>>> Thinking back on previous discussions, the primary exception has been
>>>> the API itself is the bug and needs changing.
>>>>
>>>> A contrived (and over-simple) example would be:
>>>>
>>>>    public void toUppercase(String s);
>>>>
>>>> It'd be better to fix the return type than live with bad API.
>>>>
>>>> Rare, but worth mentioning I thought.
>>>
>>> But that can still cause jar hell.
>>>
>>> If there are multiple jars in the same classloader that use the broken
>>> API, they will all have to be updated at the same time.
>>> May be tricky or impossible even if they are not from different providers.
>>>
>>> That's why binary compatibility is so important.
>>
>> Bad packaging practices causes jar hell. There's only so far we can go
>> worrying about how our code is used.
>
> What do you mean by bad packaging?

Twofold:

* Simple situation - people putting multiple versions in blindly.
j2ee.jar is the old classic there, shoving it in without understanding
what it is. That's what I was meaning by bad packaging.

* More complex - different codebases with differing dependencies. This
is always going to happen and I don't see any difference between a
linkage error due to a difference between 2.5 and 3.0 and a
functionality error due to a difference between 3.0 and 3.0.1.

>> Part of the reason I felt it worth mentioning is that binary
>> compatibility is not a magic trump card that aces everything else.
>> It's very strongly desirable but not a mandatory absolute.
>
> Given that the reason for breaking binary compat. in this example is
> that we got the API wrong originally, it seems very unfair to choose
> to fix the problem in a way that causes a potentially insoluble
> problem for classpaths with multiple dependencies on the component.

The examples of API screwups I've seen are not ones where those using
them should be. I'm not talking about changing for style, but a method
that flat out is screwed up and doesn't make sense. Anyone relying on
it would be well served by discovering the old version is messed up.

> Especially since there is an alternative that avoids the problem.
> In both cases the producers of jars that depend on our component are
> going to have to recompile and re-release in order to use the updated
> API.
> There is an additional cost of editting the source to allow for the
> renamed method/class/package, but compared with
> recompiling/re-releasing it seems to me that is a relatively small
> additional cost.

It's more fair to force every other file to be repackaged and every
other user to have to deal with it?

The reality is that we end up causing pain to everyone until we
finally have enough cruft to justify a complete repackage name; then
we hope to get it right followed by more pain to everyone as we lock
down on being a martyr to compatibility.

Hen

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

Re: [ALL] suggestion for improvement: Unify homepage layout for all commons subprojects

[Henri Yandell]

On Mon, Jan 16, 2012 at 6:49 AM, Benedikt Ritter
 wrote:
> Hi,
>
> looking at the different commons project pages, it occurs to me, that all
> pages use a slightly different layout. For example comparing Lang, BeanUtils
> and Collections with one another the first thing are the page titles:
>
> - Home
> - BeanUtils - Commons
> - Collections - Home
>
> If I were to rate this titles, I would say that "BeanUtils - Commons" is the
> best one, followed by "Collections - Home". "Home" from Lang's project page
> is clearly the worst page title I can think of.
>
> Looking at the content area, there is not much to complain about. All three
> content areas are structured nearly the same way (although IMHO BeanUtils
> content area is a bit overloaded with release informations).
>
> When it comes to the sidebar, things get completely inconsistent.
> First of all: Why doesn't Lang's homepage has a link so ApacheCon?
> Why does BeanUtils have a Documentation are and a Project Documentation
> area?
> Where do I get all the informations about developing BeanUtils from (as Lang
> and Collections have a distinct development area)?
> Why does Lang's ASF area have more links than the ones of the others?

Newer version of the site. It's almost 2 years since BeanUtils was
deployed and 4 since Collections was deployed.

> Why do the release history pages of all three projects look so completely
> different?

Not standardized. Lang's the only one with a Release History afaik.

> In addition to that, I think that one thing is really missing on all of the
> three above mentioned pages: There is no road map for future releases! How
> can I know if I should wait for the next Collections release, that provides
> generics or better start my new project using the latest release? Maybe it
> will be out next week, maybe I have to wait one year. I don't know... There
> really has to be a road map, so that the users know when they can expect the
> next release and what they can expect from it.

We don't know either.

In terms of work, the Roadmap is in JIRA - ie: look at the next
version and the issues still open. Timelines however don't exist.

> I guess, I have made my point clear, and I bet that looking at other commons
> project pages would result in finding even more layout variants.
> I don't want to study the page layout all over again, when I browse through
> the different project pages. I want everything to be at the same place (as
> far as possible). So I propose to unify all page layouts. This post is not
> supposed to present the perfect layout, but rather be a discussion starter
> on how such a layout could look like (if you guys think that a unified
> layout is needed at all...).

They're more unified than you're thinking. What you're seeing is that
they are published at wildly different times (ie: the unification is
pre-publication not after).

Hen

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

Re: [lang] What about Duration class? (org.apache.commons.lang.time)

[Henri Yandell]

On Wed, Jan 25, 2012 at 2:14 PM, Christian Grobmeier
 wrote:
> On Wed, Jan 25, 2012 at 9:17 PM, Benedikt Ritter
>  wrote:
>>> But i found only discussions about duration&  joda-time dated 2004.
>>>
>>> (http://markmail.org/thread/733yqv5zwzsngj3j)
>>> Now i really need in Duration functionality (especially such as
>>> Duration.parse(String)).
>>>
>> I heard about joda-time a while ago. My impression is, that the joda project
>> is not that active anymore (please correct me, if I'm wrong). So I would
>> vouch for additions to lang regarding durations. What I'm also really
>> missing in lang.time is conversation of durations. For example:
>> DurationUtils.convertToMinutes(long seconds).
>
> Joda Time is imho a great lib. Before a few weeks I replaced all the
> JDK stuff with Joda and it really saved my life. There was a release
> in July 2011 or so and my impression is more this lib is stable and
> does not need many releases. Actually I can't imagine a feature I miss
> in Joda at the moment.
>
>>
>>> I don't understand the Commons point on this issue.
>>>
>>> - Commons Lang doesn't need in own implementation of this
>>> functionality and you suggest use joda-time?
>>> - Commons Lang needs in simple&  lightweight implementation of Duration?
>>>
>>> Also i cannot find correspond issue in jira (but Eric Crampton in 2004
>>> wrote about
>>> "Commons Lang task list that there is a need for DateRange/Duration
>>> classes").
>>
>> As you said, it is a while ago, since this was discussed. So let's review
>> this topic again.
>>
>> What are your thoughts?
>
> Hen (who is mainly behind lang) and Gary already mentioned, they don't
> want to replicate Joda code into [lang]. I don't see any reasons why
> we should do that now. Instead I would prefer to mark the time package
> as deprecated and point users to joda. time does rely on jdk classes
> and as I have found out by own experience, it is dangerous to work
> with them.

Long-term vision wise; my expectation is to drop our time package like
a lead balloon as soon as Joda enters the JDK :)

I'd love to see a Commons Time then created on top of the Joda code
for any additons; or do it in Commons Lang if it's not going to grow
that big. I'm not sure what Stephen's plan might be once Joda is in
the JDK - probably a long vacation :)

Hen

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

Re: [all] Java 5 vs. 6

[Henri Yandell]

On Fri, Feb 10, 2012 at 6:36 PM, sebb  wrote:
> On 11 February 2012 02:23, James Carman  wrote:
>> I am +1 to allowing new major version releases to go to Java 6.  Heck,
>> I'm +1 to them choosing to jump straight to Java 7.  I don't think we
>> should require it or anything, though.
>
> The Commons versioning convention does not actually require a major
> version bump for JVM changes.
> But I would hope that a big jump (e.g. 1.5 to 1.7) would be only be
> done in a major version.

+1 for moving to Java 6. Java 5 is insecure and we should not be supporting it.

I don't see why we would have to wait on major versions for updates.

Hen

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

Re: [all] Java 5 vs. 6

[Henri Yandell]

On Fri, Feb 10, 2012 at 7:45 PM, James Carman
 wrote:
> On Fri, Feb 10, 2012 at 9:56 PM, Henri Yandell  wrote:
>> I don't see why we would have to wait on major versions for updates.
>>
>
> Well, if we compile foo-1.1 with Java 5 and then compile foo-1.2 with
> Java 6 (assuming we don't target 1.5 on the compile), doesn't that
> make them effectively binary incompatible?  Version 1.2 isn't a
> drop-in replacement for 1.1, since it requires a Java version change.
> I don't think that would be too cool.

I'd have thought they'd be fine.

A Java6 user using 1.1 upgrading to 1.2 would be able to drop it in.

A Java5 user wouldn't, but that's dropping support not binary incompatibility.

Hen

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

Re: [all] Java 5 vs. 6

[Henri Yandell]

On Fri, Feb 10, 2012 at 9:38 PM, James Carman
 wrote:
> On Fri, Feb 10, 2012 at 11:44 PM, Henri Yandell  wrote:
>>
>> I'd have thought they'd be fine.
>>
>> A Java6 user using 1.1 upgrading to 1.2 would be able to drop it in.
>>
>> A Java5 user wouldn't, but that's dropping support not binary 
>> incompatibility.
>>
>
> So, would any new features and bug fixes for 1.1 have to be released
> as 1.1.x for the Java 5 folks' sake?

Nope.

I'd accept that if we had a security issue, that 1.1.x would be
necessary for the Java 5'ers, but we've never had a security issue so
I've no reason to expect one.

> I think this is somewhat of a moot point, since there are fewer and
> fewer people using Java 5 these days (even my company is on Java 6
> surprisingly).  I'm all about charging forward.  I just don't want to
> paint ourselves in a corner.

We paint ourselves into a corner whenever we assume statements are
unchangeable. Even in my statement above I reserve the right to vote
+1 on a 1.1.x that has some valuable new feature. I take it as a given
that 'business' is fluid :)

Hen

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

Re: [lang] Java 6 now

[Henri Yandell]

On Sat, Feb 25, 2012 at 8:00 AM, Gary Gregory  wrote:
> On Sat, Feb 25, 2012 at 10:00 AM, James Carman
> wrote:
>
>> Gary,
>>
>> In this case, we're dealing with a veto to a code modification, which
>> is allowed.  Here's the information with respect to code modification
>> vetoes (http://www.apache.org/foundation/voting.html#Veto):
>>
>> "A code-modification proposal may be stopped dead in its tracks by a
>> -1 vote by a qualified voter. This constitutes a veto, and it cannot
>> be overruled nor overridden by anyone. Vetos stand until and unless
>> withdrawn by their casters.
>>
>> To prevent vetos from being used capriciously, they must be
>> accompanied by a technical justification showing why the change is bad
>> (opens a security exposure, negatively affects performance, etc. ). A
>> veto without a justification is invalid and has no weight."
>>
>> Since there is a technical justification ("it's not necessary")
>> provided with this veto, it stands until "sebb" withdraws it.
>>
>> That isn't to say that I agree with sebb's assessment, necessarily.  I
>> think we should drop Java 5 like a bad habit.  We already have a bad
>> reputation for living in the past.  We need to be more
>> forward-leaning.  We can always support older versions on older JDKs
>> if necessary (could be a YAGNI situation).  If we do jump JDK
>> versions, I'd say we should jump major version numbers (which others
>> have disagreed with in the past).  To me, version numbers are cheap
>> (look at Firefox!).
>>
>
> James,
>
> Thank you for your kind reply and refreshing my memory to our processes.
>
> At the risk of being pedantic, let me get the details right and on 'paper'
> here so that we can all be on the same page.
>
> Sebb's -1 was not a veto to a code change but to my opinion that we should
> update our platform requirement to Java 6 from 5, so there is here nothing
> to 'veto'. I guess you could call it a pre-commit-veto to avoid a sequence
> of commitJava6-veto-commitJava5.
>
> (Now let's say I change the POM to require Java 6 so changes can now be
> Java 6 changes. Is changing the POM a code change that can be vetoed?
> Angles dancing on the head of pin, bleh. Forget I just said that :) Can you
> only veto code? What about other kinds of artifacts like images,
> documentation, and so on. Perhaps our process should be more precise.)
>
> So:
>
> Is a VOTE required to change our platform requirement to Java 6 from 5?
> Because subsequence code changes can be vetoed, it seems like the simplest
> thing to do.
>
> So my key question is: if/when a VOTE is called to change our platform
> requirement to Java 6 from 5, is that vote veto-able or is all that is
> needed is the usual three +1 binding votes?
>
> As we all know, strictly speaking, a release is not vetoable, all you need
> are three +1s (but there can be -1s to code changes before the release).
>
> If such a VOTE gets a -1 and the veto's "technical justification" is that
> the change is "unnecessary", then IMO that does not qualify as a "technical
> justification".

Dunno, but I'm not touching Lang 'til we're on Java 6.

Hen

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

Re: [all] svn + JIRA

[Henri Yandell]

On Mon, Apr 30, 2012 at 7:28 AM, Sébastien Brisard
 wrote:
> 2012/4/30 Sébastien Brisard :
>> Hi,
>>
>>>
>>> Just add a comment with a copy of the SVN commit mail header?
>>>
>> Thanks.
>> I did that already. I take it there is no way to include this commit
>> in the "Subversion commits" tab?
>>
>> Sébastien
> More precisely: I added a comment with the revision number.

You probably have to reindex things on the JIRA side. I wouldn't worry
about it; in the long run that'll happen at some point and it'll be
connected.

Hen

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

Re: [Collections] Generic Fork

[Henri Yandell]

Though depends on what you're submitting. JIRA issues, no worries.
Just hit the checkbox each time you add a patch.

If you become a committer, or if you're submitting something large,
then we will ask you to sign an ICLA.

When signing an ICLA, your company may want to sign a CCLA - it's
entirely up to your employer and not required by us.

Hen

On Thu, Nov 4, 2010 at 5:54 PM, Davanum Srinivas  wrote:
> Joerg,
>
> You need to sign the ICLA and your company should file a CCLA if
> appropriate. both are listed here:
> http://www.apache.org/licenses/
>
> thanks,
> dims
>
> On Thu, Nov 4, 2010 at 8:52 PM, Grant Overby  wrote:
>> I was unaware that there is official work being done for generics. This is
>> excellent news.
>>
>> I've taken my first look at trunk & jira. I have a potential solution for
>> https://issues.apache.org/jira/browse/COLLECTIONS-237 . See my comment on
>> the issue.
>>
>> Another question:
>> I presume that I would need an officer of my company (and myself) to sign:
>> http://www.apache.org/licenses/icla.txt . Is this correct? Is this all that
>> is needed to protect the ASF?
>>
>>
>> --
>> Grant Overby
>> Senior Developer
>> FloorSoft, Inc.
>>
>> Often people, especially computer engineers, focus on the machines. They
>> think, "By doing this, the machine will run faster. By doing this, the
>> machine will run more effectively. By doing this, the machine will something
>> something something." They are focusing on machines. But in fact we need to
>> focus on humans, on how humans care about doing programming or operating the
>> application of the machines. We are the masters. They are the slaves. --
>> Yukihiro Matsumoto
>>
>>
>>
>>
>> On Thu, Nov 4, 2010 at 5:20 PM, Jörg Schaible  wrote:
>>
>>> velopment is as usual by creating patches in
>>
>
>
>
> --
> Davanum Srinivas :: http://davanum.wordpress.com
>
> -
> 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: [Collections] Generic Fork

[Henri Yandell]

On Fri, Nov 5, 2010 at 5:33 AM,   wrote:
>
> - "Henri Yandell"  a écrit :
>
>> Though depends on what you're submitting. JIRA issues, no worries.
>> Just hit the checkbox each time you add a patch.
>>
>> If you become a committer, or if you're submitting something large,
>> then we will ask you to sign an ICLA.
>>
>> When signing an ICLA, your company may want to sign a CCLA - it's
>> entirely up to your employer and not required by us.
>
> It may protect him in case his employer later consider the code did not
> initially belong to him and he did not have the right to contribute it
> to an Apache project.

Sure, it may (or may not). It also might tie things up in red tape,
especially as we don't negotiate the CCLA, something that might be
novel to some legal departments. It's up to the committer/contributor
and their employer whether they want to sign it; we stay out of it.

Hen

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

Fwd: [SANSELAN] Status and future of Sanselan?

[Henri Yandell]

Pointing this email out.

JIRA for Sanselan is a bit confusing; it needs a new version created
for the next release and the changes that are going in that version
should have a fix version set of that new version.

Ideally the 'what's in the next version?' question can be answered
with a link to JIRA.

Having discovered the pain of the iPod iThmb format, I find myself
wanting Sanselan to support that :)

Hen

-- Forwarded message --
From:  
Date: Sun, Oct 31, 2010 at 10:51 AM
Subject: [SANSELAN] Status and future of Sanselan?
To: Commons Users List 
Cc: jeff_rothenb...@acm.org, n...@dad.org


Does anyone know if a new release of Sanselan, after the current
sanselan-0.97-incubator, is in the works?  If so, are the
features, enhancements, and status of the forthcoming version
described anywhere?

What are the implications of Sanselan's having been elevated from
Apache Incubator to Commons status?

Are there any plans to release more complete Sanselan
documentation?

Are there any known issues concerning discrepancies between the
current version (0.97) of Sanselan and the latest release (2.3,
April 26, 2010) of the EXIF standard?

   Norman Shapiro


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

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

Fwd: How can I get Commons-net-2.1 Source and Binaries

[Henri Yandell]

I find myself wondering if Net should move to the Attic - is anyone
active on it and likely to do a release?


-- Forwarded message --
From: sebb 
Date: Thu, Oct 14, 2010 at 4:28 PM
Subject: Re: How can I get Commons-net-2.1 Source and Binaries
To: Commons Users List 


On 14 October 2010 13:31, James Carman  wrote:
> Why does the site list it in the release notes?

Because that was correct at the time the site was updated, i.e. before
2.1 was even proposed for release.

Note that there is no date associated with the release.

However, it's a bit misleading now, so I'll change it to 2.2.

> Do we need to move all of the jira issues to 2.2?

Possibly. Sounds like a discussion for the dev list.

> On Oct 14, 2010 3:36 AM, "Jörg Schaible"  wrote:
>> 陳雪傑 wrote:
>>
>>>
>>> Hi all
>>>
>>> How can I get Commons-net-2.1 Source and Binaries?
>>>
>>> I want get publiced Commons-net-2.1 Source and Binaries from apache,
>>> but the page (http://commons.apache.org/net/download_net.cgi) do not
>>> provide it.
>>
>> You cannot, since it was never officially released. So, yes, there is a
> tag
>> in Subversion, but nobody knows, who spread it into public, what it
> actually
>> contains and you're on your own using this code. Therefore you cannot
>> download any binaries or tar balls, it has no direct support here.
> Actually
>> you should use version 2.0 until we release the next version which will be
>
>> 2.2.
>>
>> - Jörg
>>
>>
>> -
>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>> For additional commands, e-mail: user-h...@commons.apache.org
>>
>

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

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

Re: [Primitives] Does anyone use this?

[Henri Yandell]

Something else to consider is Stephen Colebourne's Joda Primitives:

http://joda-primitives.sourceforge.net/

Commons Primitives hasn't been touched since 2005 when Stephen was
active on the component. I think it's an Attic component (ie not being
worked on and no future releases expected).

Bcc to Commons Users; moving conversation to Dev on the 2nd point.

Hen

On Tue, Nov 2, 2010 at 1:52 PM, sebb  wrote:
> Note that lack of recent activity is not necessarily a bad sign; in
> this case I think it's because the code is working fine.
> I could find no outstanding bugs for the component.
>
> On 2 November 2010 20:10, Brian Pontarelli  wrote:
>> I probably wouldn't use these collections in a factory context. If I'm 
>> concerned about speed and size, I'm going to create the primitive collection 
>> using the constructor and then use it directly. Adding in any factories, 
>> AOP, etc. is just going to add overhead.
>>
>> The original issue is really whether or not the commons library is still 
>> active or if Trove is a better choice. I'd say either library will work and 
>> I've used both. Another thing to think about is your comfort with licenses. 
>> I prefer ASL over LGPL as a rule of thumb and Trove is LGPL. I tend to avoid 
>> anything with the letters G, P and L in the license. But if you can find 
>> something with BSD, that's the way to go.
>>
>> ;)
>>
>> -bp
>>
>>
>> On Nov 2, 2010, at 1:24 PM, Martin Gainty wrote:
>>
>>>
>>> also lookup methods from factories will reliably lookup 
>>> ArrayList when bean definition has attribute
>>> dependency-check="object" but wont lookup a collection of primitives such 
>>> as int []PrimitiveDataTypeVariable even when the bean definition specified 
>>> dependency-check="simple"
>>>
>>> http://static.springsource.org/spring/docs/1.2.9/reference/beans.html
>>>
>>> thanks,
>>> Martin Gainty
>>> __
>>> Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
>>>
>>> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene 
>>> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte 
>>> Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht 
>>> dient lediglich dem Austausch von Informationen und entfaltet keine 
>>> rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von 
>>> E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
>>> Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
>>> destinataire prévu, nous te demandons avec bonté que pour satisfaire 
>>> informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie 
>>> de ceci est interdite. Ce message sert à l'information seulement et n'aura 
>>> pas n'importe quel effet légalement obligatoire. Étant donné que les email 
>>> peuvent facilement être sujets à la manipulation, nous ne pouvons accepter 
>>> aucune responsabilité pour le contenu fourni.
>>>
>>>
>>>
>>>
>>>
 From: josiah.d.hasw...@hp.com
 To: u...@commons.apache.org
 Date: Tue, 2 Nov 2010 18:42:29 +
 Subject: RE: [Primitives] Does anyone use this?

 Gnu Trove includes a set of benchmarks vs. the JCF. I don't understand why 
 this is so controversial; a developer should be able to assess the 
 suitability of a library for his or her purposes without it turning into a 
 huge debate. If dependency-management is an issue, Trove is available from 
 numerous Ivy/Maven repositories.

 Joe H. | HP Software

 -Original Message-
 From: Martin Gainty [mailto:mgai...@hotmail.com]
 Sent: Tuesday, November 02, 2010 11:41 AM
 To: u...@commons.apache.org
 Subject: RE: [Primitives] Does anyone use this?


 Brian

 how does primitive collections implementation perform better than JDK 
 collections?

 thanks,
 Martin
 __
 please do not alter or disrupt this transmission. thank you





> Subject: Re: [Primitives] Does anyone use this?
> From: br...@pontarelli.com
> Date: Tue, 2 Nov 2010 11:32:01 -0600
> To: u...@commons.apache.org
>
> I would assume once you get out of the autoboxing caches the performance 
> will get even worse. It really depends on the application, but I've found 
> a number of spots where primitive collections work much better than 
> autoboxing and JDK collections.
>
> -bp
>
>
> On Nov 2, 2010, at 11:25 AM, James Carman wrote:
>
>> Yet another dependency to add to the mix.
>>
>> On Tue, Nov 2, 2010 at 1:17 PM, Cogen, David - 1008 - MITLL
>>  wrote:
>>>
>>> 
>>> From: jcar...@carmanconsulting.com [jcar...@carmanconsulting.com] On 
>>> Behalf Of James Carman [ja...@carmanconsulting.com]
>>> Sent: Tuesday, November 02, 2010 12:30 PM
>>> To: Commons Users

Re: [SANSELAN] Status and future of Sanselan?

[Henri Yandell]

What will the version number be for the next release?

On Sun, Nov 7, 2010 at 8:25 AM, Charles Matthew Chen
 wrote:
>   I think a new release is overdue.  I've been meaning to do it when
> I find the time.  If someone else would like to beat me to it, they're
> welcome to go ahead.  Almost everything new in the release is covered
> by closed JIRA tickets.
>
>
>> What are the implications of Sanselan's having been elevated from
> Apache Incubator to Commons status?
>
>   I'm not sure what you mean?  Has the code changed?  No.
>
>> Are there any plans to release more complete Sanselan
> documentation?
>
>   Agreed, this is (also) long overdue.
>
>> Are there any known issues concerning discrepancies between the
> current version (0.97) of Sanselan and the latest release (2.3,
> April 26, 2010) of the EXIF standard?
>
>   I haven't had a chance to look at this at all.
>
> Matthew
>
>
> On Sun, Nov 7, 2010 at 2:14 PM, Henri Yandell  wrote:
>> Pointing this email out.
>>
>> JIRA for Sanselan is a bit confusing; it needs a new version created
>> for the next release and the changes that are going in that version
>> should have a fix version set of that new version.
>>
>> Ideally the 'what's in the next version?' question can be answered
>> with a link to JIRA.
>>
>> Having discovered the pain of the iPod iThmb format, I find myself
>> wanting Sanselan to support that :)
>>
>> Hen
>>
>> -- Forwarded message --
>> From:  
>> Date: Sun, Oct 31, 2010 at 10:51 AM
>> Subject: [SANSELAN] Status and future of Sanselan?
>> To: Commons Users List 
>> Cc: jeff_rothenb...@acm.org, n...@dad.org
>>
>>
>> Does anyone know if a new release of Sanselan, after the current
>> sanselan-0.97-incubator, is in the works?  If so, are the
>> features, enhancements, and status of the forthcoming version
>> described anywhere?
>>
>> What are the implications of Sanselan's having been elevated from
>> Apache Incubator to Commons status?
>>
>> Are there any plans to release more complete Sanselan
>> documentation?
>>
>> Are there any known issues concerning discrepancies between the
>> current version (0.97) of Sanselan and the latest release (2.3,
>> April 26, 2010) of the EXIF standard?
>>
>>    Norman Shapiro
>>
>>
>> -
>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>> For additional commands, e-mail: user-h...@commons.apache.org
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

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

Re: [lang3] Test Fail in Headless Mode (at Least on a Mac)

[Henri Yandell]

+1 to make a change; it really irritates on OS X when AWT takes over
control of the focus.

On Fri, Nov 19, 2010 at 8:08 AM, Stefan Bodewig  wrote:
> Hi,
>
> I'm pretty sure lang3 isn't the only project that is affected, it's just
> the first one we've seen it.  "we" ist the Gump project.
>
> Sander has set up a Mac to run Gump[1] and commons-lang3 is Gump's
> guinea pig for Maven 3.x builds in the workspace we use for developer
> tests and new installations.
>
> The commons-lang3 builds fail[2] and too me it looks as if this was
> because AWT is not running in headless mode, this in [3] looks
> suspicious:
>
> java.lang.InternalError: Can't connect to window server - not enough 
> permissions.
>
> As can be seen in [2] MAVEN_OPTS is set up to make mvn run in headless
> mode but it doesn't affect the tests - likely because the tests run in a
> forked VM and the same property must be set in the surefire
> configuration.
>
> I am suprised the problem doesn't show up in the other CI builds.
>
> There likely is a way we could set additional properties for the maven
> run (like surefire specific system properties or telling it not to
> fork), but (a) this is beyond my Maven foo and (b) would have to be
> repeated in other environments that have the same problem as well.  Does
> anybody know of a better fix?
>
> Stefan
>
> [1] http://adam.apache.org/gump/
>
> [2] 
> http://adam.apache.org/gump/commons-lang-3.x/commons-lang3/gump_work/build_commons-lang-3.x_commons-lang3.html
>
> [3] 
> http://adam.apache.org/gump/commons-lang-3.x/commons-lang3/gump_file/org.apache.commons.lang3.event.EventUtilsTest.txt.html
>
> -
> 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: ASF newbie

[Henri Yandell]

Two options spring to mind; the first is to dig through the Apache
Incubator and look for a project that piques your interest. You can
quite quickly have a strong impact on a project there. "Your interest"
can be fairly vague; it might be that the language is one you want to
learn, it might be that you'd like to learn more about image
specifications or implement a codec. It works best when it's something
you're already using; mine was a PDA IDE that didn't support regexp in
its Find menu option.

The second is to look at existing projects and dip into the occasional
bug or enhancement. Commons is good for this kind of dim sum
contribution and it can be a good way to get used to the general Open
Source style before finding a project you want to dive deeper in to.
Commons Lang (as the example I know best) often has issues in JIRA
where the patch comes from a non-committer (and they weren't the
reporter).

Hen

On Thu, Nov 25, 2010 at 4:59 PM, Nuwan Aramabage
 wrote:
> Hi,
> I'm a java programmer who do have intermediate knowledge in industry
> level software development.
> I have joined this mailing list recently however at the moment I'm
> blank in which project I should have been involved.
> I have ran through the initial documents that explains how to select a
> project to contribute.The main point they mentioned is
> select a project based on your interest.
>
> as a beginner , I think project complexity and maturity does matter
> when choosing a project to be contributed.How can i find
> less complex ,less mature ASF project since I'm a beginner ?. I'm
> expecting a solid answer form big fishes in the community.
>
> Thanks.
>
> With regards,
>
> Nuwan Arambage.
>
> -
> 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: [lang3] Test Fail in Headless Mode (at Least on a Mac)

[Henri Yandell]

On Wed, Nov 24, 2010 at 3:51 AM, sebb  wrote:
> On 24 November 2010 11:02, Stefan Bodewig  wrote:
>> On 2010-11-24, sebb wrote:
>>
>>> On 24 November 2010 09:46, Stefan Bodewig  wrote:
 On 2010-11-22, Jörg Schaible wrote:
>>
> Stefan Bodewig wrote:
>>
>> The commons-lang3 builds fail[2] and too me it looks as if this was
>> because AWT is not running in headless mode,
>>
 confirmed by passing -DargLine=-Djava.awt.headless=true to mvn - the
 builds now pass.
>>
>> I am suprised the problem doesn't show up in the other CI builds.
>>
 Still surprised 8-)
>>
 It doesn't show up inside Gump on Linux or FreeBSD running OpenJDK or
 the FreeBSD port of Sun's VM either - maybe this codebase's AWT detects
 there is no X-Server and switches to headless mode without any help.
>>
>>> Or are those nodes running a frame buffer (I think that is the correct 
>>> name)?
>>
>> I don't recall installing Xvfb (the X server running in a virtual frame
>> buffer) but it could have been pulled in as a dependency - and I'm
>> pretty sure we don't start it even if it is installed.  No, I don't
>> think the builds have any X server to connect to.
>>
>>> Since there are headless hosts, maybe code which is supposed to be
>>> able to run anywhere (e.g. LANG) needs to take this into account?
>>
>>> I.e. Perhaps MacGump has found a bug in Lang?
>>
>> The tests that failed are the ones for the event package.  I don't see
>> any uses of AWT in the main code but the tests use AWT classes
>> (ActionEvent and ActionListener).  It seems as if the static initializer
>> of either class already requires a working window system on a Mac - it
>> may not be required on OpenJDK's AWT.
>>
>> I don't think the lang3 code requires a window system - so no bug in the
>> main code - but its tests do.
>
> IMO the tests should then be fixed (I may have time to look later).
>
> If there is a suitable alternative to the AWT events then use that,
> otherwise allow for the test failure when running headless.
>
> Seems to me it's more useful for Gump to point out these problems than
> to try and hide them.

+1.

Perhaps:

javax.naming.event.ObjectChangeListener
javax.naming.event.NamingEvent

Hen

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

Re: [lang3] Test Fail in Headless Mode (at Least on a Mac)

[Henri Yandell]

On Fri, Nov 26, 2010 at 12:49 AM, Henri Yandell  wrote:
> On Wed, Nov 24, 2010 at 3:51 AM, sebb  wrote:
>> On 24 November 2010 11:02, Stefan Bodewig  wrote:
>>> On 2010-11-24, sebb wrote:
>>>
>>>> On 24 November 2010 09:46, Stefan Bodewig  wrote:
>>>>> On 2010-11-22, Jörg Schaible wrote:
>>>
>>>>>> Stefan Bodewig wrote:
>>>
>>>>>>> The commons-lang3 builds fail[2] and too me it looks as if this was
>>>>>>> because AWT is not running in headless mode,
>>>
>>>>> confirmed by passing -DargLine=-Djava.awt.headless=true to mvn - the
>>>>> builds now pass.
>>>
>>>>>>> I am suprised the problem doesn't show up in the other CI builds.
>>>
>>>>> Still surprised 8-)
>>>
>>>>> It doesn't show up inside Gump on Linux or FreeBSD running OpenJDK or
>>>>> the FreeBSD port of Sun's VM either - maybe this codebase's AWT detects
>>>>> there is no X-Server and switches to headless mode without any help.
>>>
>>>> Or are those nodes running a frame buffer (I think that is the correct 
>>>> name)?
>>>
>>> I don't recall installing Xvfb (the X server running in a virtual frame
>>> buffer) but it could have been pulled in as a dependency - and I'm
>>> pretty sure we don't start it even if it is installed.  No, I don't
>>> think the builds have any X server to connect to.
>>>
>>>> Since there are headless hosts, maybe code which is supposed to be
>>>> able to run anywhere (e.g. LANG) needs to take this into account?
>>>
>>>> I.e. Perhaps MacGump has found a bug in Lang?
>>>
>>> The tests that failed are the ones for the event package.  I don't see
>>> any uses of AWT in the main code but the tests use AWT classes
>>> (ActionEvent and ActionListener).  It seems as if the static initializer
>>> of either class already requires a working window system on a Mac - it
>>> may not be required on OpenJDK's AWT.
>>>
>>> I don't think the lang3 code requires a window system - so no bug in the
>>> main code - but its tests do.
>>
>> IMO the tests should then be fixed (I may have time to look later).
>>
>> If there is a suitable alternative to the AWT events then use that,
>> otherwise allow for the test failure when running headless.
>>
>> Seems to me it's more useful for Gump to point out these problems than
>> to try and hide them.
>
> +1.
>
> Perhaps:
>
> javax.naming.event.ObjectChangeListener
> javax.naming.event.NamingEvent

I've fixed this in r1040879. Generally I opted for using java.beans listeners.

Hen

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

Re: [lang3] Test Fail in Headless Mode (at Least on a Mac)

[Henri Yandell]

On Wed, Dec 1, 2010 at 7:57 AM, Matt Benson  wrote:
>
> On Dec 1, 2010, at 2:45 AM, Stefan Bodewig wrote:
>
>> On 2010-12-01, Henri Yandell wrote:
>>
>>> I've fixed this in r1040879.
>>
>> I can confirm it is fixed for Gump as well.  I removed all awt.headless
>> settings from the Gump descriptor and the build still passes on adam.
>>
>
> Having thought I was following this thread, being an OSX user, and having 
> worked in the event package I can only apologize for having apparently 
> skimmed over the part of the thread that revealed that this is where the 
> fault was.  Thanks for fixing this, Hen.
>
> -Matt

No prob, gives me something to do :)

Hen

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

Re: OGNL as a part of Commons

[Henri Yandell]

+1.

Just like to point out that duplication of featureset is not an issue
in Commons.

Hen

On Sun, Dec 12, 2010 at 11:38 PM, Lukasz Lenart
 wrote:
> Hi all,
>
> I want to ask you all, is it possible to include OGNL
> (https://github.com/jkuhnert/ognl , http://www.opensymphony.com/ognl/
> ) into Commons project?
>
> As I know OGNL is used by few ASF projects (Struts 2, Tapestry) and
> right now it's homeless project. It's very hard to prepare a new
> release, to update documentation, and so on. It would be much better
> to include it in Commons and base on ASF infrastructure. Right now I'm
> the only contributor to that project and I've been talking with the
> authors of OGNL and they agreed to move OGNL to ASF.
>
> What do you think?
>
>
> Kind regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
> Kapituła Javarsovia http://javarsovia.pl
>
> -
> 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] math expression parser

[Henri Yandell]

Or kick it off at apache-extras.org :)

On Thu, Jan 6, 2011 at 12:17 AM, Paul Libbrecht  wrote:
> Frank,
>
> why not propose this as another project?
> It requires more maintenance, that is true.
> Sandbox is designed for that, including to evaluate if there are user bases.
>
> I tend to feel your contribution is not useless.
> A readable syntax instead of java syntax for formulæ that are rather longer 
> than 3 operations.
> Somewhat in the comfort of using xpath instead of calling getChildren of all 
> sorts.
>
> paul
>
>
> Le 5 janv. 2011 à 22:12, frank asseg a écrit :
>
>> Hola Gary!
>>
>> On 05.01.2011 22:04, Gary Gregory wrote:
>>> Why should this be in [lang] instead of [math]?
>> I actually thought about posting on [math] but when i browsed the math
>> library i gained the impression that it's much more concerned with more
>> complex mathematical issues like integration of numerical analysis
>> rather than parsing user input, so imho i decided to post to [lang], the
>> library which i always associate with Strings ;)
>
>
> -
> 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 - useful to have float/double equals method?

[Henri Yandell]

-1 on enhancements in LANG 2.x; by which I mean that I personally am
not interested in spending effort on 2.x being anything other than a
critical bugfix legacy version.

Hen

On Wed, Jan 12, 2011 at 8:21 AM, sebb  wrote:
> On 12 January 2011 15:31, Ted Dunning  wrote:
>> Why aren't the comparison methods in java (since 1.4) good enough?
>
> 1) LANG 2.x targets 1.3
>
> 2) compare does not take into account that floats/doubles are inexact,
> so some tolerance is needed.
>
> See http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm
> for useful explanation.
>
> Furthermore, both compare() and equals() treat +0 and -0 as being unequal.
>
>> http://download.oracle.com/javase/1.4.2/docs/api/java/lang/Double.html#compare(double,
>> double)
>>
>> http://download.oracle.com/javase/1.4.2/docs/api/java/lang/Float.html#compare(float,
>> float)
>>
>> On Wed, Jan 12, 2011 at 3:15 AM, sebb  wrote:
>>
>>> Would it be useful to add an equals method for float/double?
>>>
>>
>
> -
> 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] What's left for 3.0?

[Henri Yandell]

See JIRA :)

https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310481&fixfor=12311714&resolution=-1&sorter/field=priority&sorter/order=DESC

On Fri, Jan 14, 2011 at 12:42 PM, Matt Benson  wrote:
> See title.
>
> -Matt
>
> -
> 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: [codec] want to commit our Phonex codec

[Henri Yandell]

Submitting the patch as a JIRA issue is also good:

https://issues.apache.org/jira/browse/CODEC

On Sun, Jan 16, 2011 at 12:18 PM, Gary Gregory
 wrote:
> Bonjour Nicolas,
>
> The best way to do that is to contribute a patch including a battery of unit 
> tests. You should do a local build to make sure the code has good code 
> coverage through cobertura.
>
> Make sure the code is free of patents and is licensed under ASL 2.0.
>
> You'll also want to adhere to style and code guidelines. Look at checkstyle 
> and findbugs reports.
>
> Cheers
> Gary
>
> On Jan 16, 2011, at 14:50, "Nicolas Géraud"  wrote:
>
>> hello world,
>>
>> I’m a French developer and in my team we have implemented the Phonex
>> algorithm to use with the wonderful union solr/lucene. Phonex is the soundex
>> for french idiom and we want to free our dev.
>> How to do that ?
>>
>> It's not to late so : happy new year !
>
> -
> 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] What's left for 3.0?

[Henri Yandell]

I took care of a few issues. 9 left to go; or they need to be declared
as 'fix in 3.1 or 4.0'. I think at this point that anything that is a
backwards incompatibility but not for 3.0 (i.e. the potential 4.0)
should be resolved as 'wontfix'. The StrTokenizer issue jumps to mind.

Also need to look for TODO statements in the code; I think I have a
few in the translator stuff that I need to tidy up.

Hen

On Sat, Jan 15, 2011 at 10:25 AM, Henri Yandell  wrote:
> See JIRA :)
>
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310481&fixfor=12311714&resolution=-1&sorter/field=priority&sorter/order=DESC
>
> On Fri, Jan 14, 2011 at 12:42 PM, Matt Benson  wrote:
>> See title.
>>
>> -Matt
>>
>> -
>> 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] What's left for 3.0?

[Henri Yandell]

And now down to 6 issues.

1 of them is a non-issue for release (JDK 1.7 has bugs); 1 is documentation.

Of the other 4:

LANG-462 - FastDateFormat supporting parse.  Need to look at the
patches. Blocker for 3.0.
LANG-544 - ToStringStyle.registry thread issues.   Need to consider
solution. Not a blocker for 3.0 imo.
LANG-624 - java.version vs java.specification.version.  I'm +1 to
moving to specification.version. Blocker for 3.0.
LANG-288 - StrTokenizer needs to support access to the token
separators.  It's an enhancement; while now is the time to implement
this, no one has. I'm thinking it should be punted to 3.1 and if the
solution involves incompatibility, it can wait for 4.0.

So mostly we need to look at LANG-462, and resolve the debate on LANG-624.

Hen

On Sun, Jan 16, 2011 at 9:37 PM, Henri Yandell  wrote:
> I took care of a few issues. 9 left to go; or they need to be declared
> as 'fix in 3.1 or 4.0'. I think at this point that anything that is a
> backwards incompatibility but not for 3.0 (i.e. the potential 4.0)
> should be resolved as 'wontfix'. The StrTokenizer issue jumps to mind.
>
> Also need to look for TODO statements in the code; I think I have a
> few in the translator stuff that I need to tidy up.
>
> Hen
>
> On Sat, Jan 15, 2011 at 10:25 AM, Henri Yandell  wrote:
>> See JIRA :)
>>
>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310481&fixfor=12311714&resolution=-1&sorter/field=priority&sorter/order=DESC
>>
>> On Fri, Jan 14, 2011 at 12:42 PM, Matt Benson  wrote:
>>> See title.
>>>
>>> -Matt
>>>
>>> -
>>> 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] What's left for 3.0?

[Henri Yandell]

3 issues now, by punting the three non-blockers up to 3.1.

Mostly it means that we need to decide what to do on LANG-624 and then
get releasing.

Hen

On Sun, Jan 16, 2011 at 10:03 PM, Henri Yandell  wrote:
> And now down to 6 issues.
>
> 1 of them is a non-issue for release (JDK 1.7 has bugs); 1 is documentation.
>
> Of the other 4:
>
> LANG-462 - FastDateFormat supporting parse.  Need to look at the
> patches. Blocker for 3.0.
> LANG-544 - ToStringStyle.registry thread issues.   Need to consider
> solution. Not a blocker for 3.0 imo.
> LANG-624 - java.version vs java.specification.version.  I'm +1 to
> moving to specification.version. Blocker for 3.0.
> LANG-288 - StrTokenizer needs to support access to the token
> separators.  It's an enhancement; while now is the time to implement
> this, no one has. I'm thinking it should be punted to 3.1 and if the
> solution involves incompatibility, it can wait for 4.0.
>
> So mostly we need to look at LANG-462, and resolve the debate on LANG-624.
>
> Hen
>
> On Sun, Jan 16, 2011 at 9:37 PM, Henri Yandell  wrote:
>> I took care of a few issues. 9 left to go; or they need to be declared
>> as 'fix in 3.1 or 4.0'. I think at this point that anything that is a
>> backwards incompatibility but not for 3.0 (i.e. the potential 4.0)
>> should be resolved as 'wontfix'. The StrTokenizer issue jumps to mind.
>>
>> Also need to look for TODO statements in the code; I think I have a
>> few in the translator stuff that I need to tidy up.
>>
>> Hen
>>
>> On Sat, Jan 15, 2011 at 10:25 AM, Henri Yandell  wrote:
>>> See JIRA :)
>>>
>>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310481&fixfor=12311714&resolution=-1&sorter/field=priority&sorter/order=DESC
>>>
>>> On Fri, Jan 14, 2011 at 12:42 PM, Matt Benson  wrote:
>>>> See title.
>>>>
>>>> -Matt
>>>>
>>>> -
>>>> 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] enum for Java Version [was svn commit: r1065174 - ...]

[Henri Yandell]

The enum is less to do with Android and more to do with the float and
int APIs being bizarre. The enum is to have something more useable.

We could drop the enum and just go with String values.

Hen

On Sun, Jan 30, 2011 at 1:34 PM, Stephen Colebourne
 wrote:
> I have no philosophical problem with adding to an enum in a later
> release, its designed to be compatible (don't persist the ordinal).
> However, I'm unconvinced that an enum is the right solution here. I
> should probably study the details, but if Android is broken perhaps
> thats just how it is.
> Stephen
>
>
> On 30 January 2011 21:29, Niall Pemberton  wrote:
>> IMO this is a really bad idea. Enum's shouldn't ever change, since
>> changing them can break code that use them. Clearly this enum will
>> need to change every time a new version of Java is released. I'm
>> against this.
>>
>> Niall
>>
>> On Sun, Jan 30, 2011 at 3:48 AM,   wrote:
>>> Author: bayard
>>> Date: Sun Jan 30 03:48:40 2011
>>> New Revision: 1065174
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1065174&view=rev
>>> Log:
>>> Removed isJavaVersionAtLeast(float) and (int), and added an enum variant 
>>> with the new JavaVersion enum. Updated the rest of the code, switched 
>>> isJavaVersionAtLeast over to using java.specification.version and not 
>>> java.version (the vendor code) and dropped JAVA_VERSION_TRIMMED, 
>>> JAVA_VERSION_FLOAT and JAVA_VERSION_INT. See: LANG-624
>>>
>>> Added:
>>>    
>>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/JavaVersion.java
>>>    (with props)
>>> Modified:
>>>    
>>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ClassUtils.java
>>>    
>>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/SystemUtils.java
>>>    
>>> commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/CharEncodingTest.java
>>>    
>>> commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/ClassUtilsTest.java
>>>    
>>> commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/LocaleUtilsTest.java
>>>    
>>> commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/SystemUtilsTest.java
>>>    
>>> commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/math/NumberUtilsTest.java
>>>    
>>> commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/text/ExtendedMessageFormatTest.java
>>>    
>>> commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/time/DateUtilsTest.java
>>>
>>> Modified: 
>>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ClassUtils.java
>>> URL: 
>>> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ClassUtils.java?rev=1065174&r1=1065173&r2=1065174&view=diff
>>> ==
>>> --- 
>>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ClassUtils.java
>>>  (original)
>>> +++ 
>>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ClassUtils.java
>>>  Sun Jan 30 03:48:40 2011
>>> @@ -436,7 +436,7 @@ public class ClassUtils {
>>>      * @return true if assignment possible
>>>      */
>>>     public static boolean isAssignable(Class[] classArray, Class[] 
>>> toClassArray) {
>>> -        return isAssignable(classArray, toClassArray, 
>>> SystemUtils.isJavaVersionAtLeast(1.5f));
>>> +        return isAssignable(classArray, toClassArray, 
>>> SystemUtils.isJavaVersionAtLeast(JavaVersion.JAVA_1_5));
>>>     }
>>>
>>>     /**
>>> @@ -521,7 +521,7 @@ public class ClassUtils {
>>>      * @return true if assignment possible
>>>      */
>>>     public static boolean isAssignable(Class cls, Class toClass) {
>>> -        return isAssignable(cls, toClass, 
>>> SystemUtils.isJavaVersionAtLeast(1.5f));
>>> +        return isAssignable(cls, toClass, 
>>> SystemUtils.isJavaVersionAtLeast(JavaVersion.JAVA_1_5));
>>>     }
>>>
>>>     /**
>>>
>>> Added: 
>>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/JavaVersion.java
>>> URL: 
>>> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/JavaVersion.java?rev=1065174&view=auto
>>> ==
>>> --- 
>>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/JavaVersion.java
>>>  (added)
>>> +++ 
>>> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/JavaVersion.java
>>>  Sun Jan 30 03:48:40 2011
>>> @@ -0,0 +1,82 @@
>>> +/*
>>> + * Licensed to the Apache Software Foundation (ASF) under one or more
>>> + * contributor license agreements.  See the NOTICE file distributed with
>>> + * this work for additional information regarding copyright ownership.
>>> + * The ASF licenses this file to You under the Apache License, Version 2.0
>>> + * (the "License"); you may not use this file except in compliance with
>>> + * the License.  You may obtain a copy of the License at
>>> + *
>>> + *      http://www.apache.org/lic

Feathercast on Apache Commons

[Henri Yandell]

Our own Gary Gregory being interviewed by Feathercast.org:

  http://feathercast.org/?p=97

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

Re: [lang] Differences between 3.0 and 2.6

[Henri Yandell]

Just beat me; 2 hours before I got my script running again! :)

http://people.apache.org/~bayard/lang-clirr/lang-clirr-report.html

I'll keep that going for the moment as it might be useful to keep that
as a 2.x to 3.x diff once we're using the main one for a 3.x to 3.0
diff.

When releasing 3.0, we should copy the clirr-report over. Might be
worth doing that for all old versions as energy permits.

Hen

On Sun, Feb 6, 2011 at 7:55 AM, Niall Pemberton
 wrote:
> I created a re-packaged version of Lang 2.6 so that we can produce a
> more meaningful CLIRR report to see the real changes between 2.6 and
> 3.0:
>    http://svn.apache.org/viewvc?view=revision&revision=1067685
>
> I have refreshed the Lang site, with the clirr report run against that 
> version:
>    http://commons.apache.org/lang/clirr-report.html
>
> Niall
>
> -
> 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] propse new ObjectExistsException extends IllegalArgumentException

[Henri Yandell]

To define a bar on exceptions; they need to be used by Commons Lang.
In 3.0 we've dropped the "this would be a better name for an
exception" exceptions as it's too easy for that to grow and grow.

Hen

On Fri, Feb 11, 2011 at 6:01 AM, Simone Tripodi
 wrote:
> Hi Thomas,
> can you describe please in which non-JPA context the exception can
> become useful?
> Many thanks in advance, have a nice day,
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Fri, Feb 11, 2011 at 10:31 AM, thomas menzel  
> wrote:
>> hi,
>>
>> i suggest a new exception under the commons.lang.exception namely
>>
>> ObjectExistsException extends IllegalArgumentException.
>>
>> in the jpa world there is already one like this, bit i think it has merit 
>> for also other cases outside of jpa and hence i would like to see it defined 
>> in apache's commons.lang.exception.
>>
>> what do u think?
>>
>> --
>> NEU: FreePhone - kostenlos mobil telefonieren und surfen!
>> Jetzt informieren: http://www.gmx.net/de/go/freephone
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

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

[collections] retire or release?

[Henri Yandell]

Seeing this bug reported for the Nth time:

https://issues.apache.org/jira/browse/COLLECTIONS-371

I wonder if collections should be declared dead. It's a dumb bug,
(removeAll calling retainAll), and users have had to put up with it
for years now.

Hen

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

Re: [collections] retire or release?

[Henri Yandell]

I'd like to see a 3.3; I think we have a branch that had a lot of
bugfixes on it before the 4.0 merge.

4.0 - painful to have a working product there and not release, yet not
sure there's much point if there isn't enough energy to do subsequent
releases.

Hen

On Sun, Feb 20, 2011 at 9:17 AM, Matt Benson  wrote:
> Obviously it sucks how long it's been since we've had a release.  Apparently
> Stephen C was the heart & soul of the project.  :)  I've been trying to make
> a little time for it lately, but it would seem that several of us across the
> project have been somewhat short of time for the past couple of years now.
>  I just hate to see us retire it when we're *so* close to having 4.0
> ready aren't we?
>
> Matt
>
> On Sun, Feb 20, 2011 at 4:45 AM, Jochen Wiedmann
> wrote:
>
>> Release, then retire?
>>
>>
>> On Sun, Feb 20, 2011 at 7:09 AM, Henri Yandell  wrote:
>> > Seeing this bug reported for the Nth time:
>> >
>> > https://issues.apache.org/jira/browse/COLLECTIONS-371
>> >
>> > I wonder if collections should be declared dead. It's a dumb bug,
>> > (removeAll calling retainAll), and users have had to put up with it
>> > for years now.
>> >
>> > Hen
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > For additional commands, e-mail: dev-h...@commons.apache.org
>> >
>> >
>>
>>
>>
>> --
>> I Am What I Am And That's All What I Yam (Popeye)
>>
>> -
>> 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: Sanselan: commit access?

[Henri Yandell]

Both the committer and PMC addition process happens on the private PMC
list so we can be candid, yet polite (knowing full well that people
can read the archives later on :) ).

The kick off for a vote is organic; either an existing member flags
that it should happen, or the individual in question hits a barrier
that makes it hard for them to increase their level of contribution
and they politely raise it in an email (like Damjan has done).

At that our extremely well oiled process kicks into gear if anyone
should need the gear workings for a Model T Ford, let us know :)

If anyone, like Damjan, wants to be a committer and can justify why
[i.e. the contributions that explain why you and not any other
contributor to the mailing list/JIRA], please feel free to step up and
do as Damjan did.

Hen

On Thu, Feb 24, 2011 at 5:14 AM, Charles Matthew Chen
 wrote:
> Hi Damjan,
>
>   I'm sorry your commit has been in limbo - its my fault.  I fully
> support your becoming a committer.  You've made a steady set of
> high-quality contributions to the project.  I've committed every patch
> you've submitted with hardly any changes.  These patches have included
> significant new functionality.  Moreover, I've been unable to
> participate meaningfully due to other commitments, and I'd love to see
> the project add an active committer.
>
>   Having said that, I'm not sure how the committer nomination &
> election process works.  My understanding is that you have to be
> nominated by a member of the Apache Commons Project Management
> Committee (PMC).  I myself am not a PMC.
>
>   Would any PMCs reading this list care to step in?  It would be
> helpful to clarify how the committer nomination and election process
> works.
>
> Cheers,
>   Charles Matthew Chen
>
>
>
> On Wed, Feb 23, 2011 at 3:53 PM, Damjan Jovanovic  
> wrote:
>> Hi
>>
>> My large patch to Sanselan
>> (https://issues.apache.org/jira/browse/SANSELAN-49) has been sitting
>> in Jira for 6 weeks with no comment. With it, > 50% of all image
>> formats in Sanselan will have been written by me, and I've been
>> practically the only contributor of late, so can I please have commit
>> access?
>>
>> Thank you
>> Damjan
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

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

[site] release pain

[Henri Yandell]

The http://commons.apache.org/releases/prepare.html site seems to
imply that the latest way to build the zip/tar.gzs is with:

  mvn -Prc -DcreateChecksum=true install

Running that, I don't get what I'd expect.

Thought I'd report that. For now I'm going to use assembly:assembly.

Hen

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

Re: [codec] Error in the Caverphone implemention

[Henri Yandell]

Thanks Martin and Gary - sorry for my screwup.

Very happy that you found the Caverphone code however Martin :)

Hen

On Tue, Mar 1, 2011 at 9:59 AM, Gary Gregory  wrote:
> The fix is in SVN and scheduled for inclusion in the upcoming Codec 1.5
> release.
>
> Thank you,
> Gary
>
> On Tue, Mar 1, 2011 at 6:05 AM, Martin Nybo Andersen  wrote:
>
>> Hi,
>>
>> On Mon, 28 Feb 2011, Matt Benson wrote:
>>
>>  Finally, given the fact that we are discussing patches (which have to
>>> be granted IP blah blah blah anyway) as well as the fact that you are
>>> not subscribed to the developer list, this exchange should be
>>> conducted in JIRA.
>>>
>>> Matt
>>>
>>
>> I wrote the mail to raise a flag. You saw it, which was my intention. I'm
>> happy now.
>>
>> To create a jira account for this minor bug seems to be overkill for me.
>> Remember that the harder it is to report a bug, the fewer bugs will be
>> reported.
>>
>> I am not subscribed to this mailing list for the same reason.
>>
>> What you do with the bug now, is for you to decide.
>>
>>
>>> On Mon, Feb 28, 2011 at 10:04 AM, Gary Gregory 
>>> wrote:
>>>
 Would you be able to include a unit test patch in your diff file?

>>>
>> new Caverphone().encode("mbmb") currently returns "MMP111" while it
>> should return "MPM111".
>>
>>
 Also, it seems that the examples from

 http://en.wikipedia.org/wiki/Caverphone

 do not match our code:

            {"Lee", "L1"},
            {"Thompson", "TMPSN1"},


>> These Caverphones seems to be version 1. Version 2 which is implemented in
>> apache.commons uses 10-letter-codes.
>>
>>  Hm...

 Thank you,
 Gary

 On Mon, Feb 28, 2011 at 8:13 AM, Martin Nybo Andersen >>> >wrote:

  Hi,
>
> I've found an error in the Caverphone language codec.
>
> According to the specs at page 2 line 6:
> "If the name ends with mb make it m2".
>
> Apparently is has been interpreted as:
> "If the name _starts_ with mb make it m2".
>
> The attached patch will fix it.
>
> Please CC me, as I'm not subscribed.
>

>>
>> Regards,
>> Martin Nybo Andersen
>
>
>
>
> --
> Thank you,
> Gary
>
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>

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

[VOTE] Release Commons Lang 3.0 (RC1)

[Henri Yandell]

Looking to release 3.0; there's not been a lot of JIRA activity and
it's 9 months or so since we released the beta.

Downloads:

  http://people.apache.org/~bayard/commons-lang3-RC1/

Maven repo entry:

  http://people.apache.org/~bayard/commons-lang3-RC1/maven/

Website:

  http://people.apache.org/~bayard/commons-lang3-RC1/site/

Tag:

  https://svn.apache.org/repos/asf/commons/proper/lang/tags/LANG_3_0_RC1

[ ] +1
[ ] -1, because:


Thanks,

Hen

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

Re: [VOTE] Release Commons Lang 3.0 (RC1)

[Henri Yandell]

On Thu, Mar 3, 2011 at 4:01 AM, sebb  wrote:
> On 3 March 2011 07:39, Henri Yandell  wrote:
>> Looking to release 3.0; there's not been a lot of JIRA activity and
>> it's 9 months or so since we released the beta.
>>
>> Downloads:
>>
>>  http://people.apache.org/~bayard/commons-lang3-RC1/
>>
>> Maven repo entry:
>>
>>  http://people.apache.org/~bayard/commons-lang3-RC1/maven/
>
> Are you not using Nexus?

Nope. Can you explain how to use it for Commons?

Hen

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

Re: [VOTE] Release Commons Lang 3.0 (RC1)

[Henri Yandell]

*waves hands* Beta release, ages ago, 3.0, started, ages, Blue Meanies!

That said - excellent feedback, I'll try to go through it tonight.

Cancelling vote; but more feedback from anyone would be excellent.

Hen

On Thu, Mar 3, 2011 at 3:59 AM, Stephen Colebourne  wrote:
> I'm not overly enthused about some of the changes, but since I've not
> been paying attention its difficult for me to vote/block. Anyway here
> is my review:
>
> ArrayUtils.hashCode() has been removed, but it had different
> functionality to Arrays.hashCode wrt nested arrays.
>
>        Object[] arrayA = new Object[] {new boolean[] {true, false},
> new int[] {6, 7}};
>        Object[] arrayB = new Object[] {new boolean[] {true, false},
> new int[] {6, 7}};
>        assertEquals(true, Arrays.hashCode(arrayB) == Arrays.hashCode(arrayA));
>
> I don't love the new Pair class. We have an interface based version
> here at OpenGamma to allow primitive implementations for performance.
> I might be able to get our code released if there was interest.
>
> ArrayUtils.toArray() javadoc has example code that won't compile
> (missing "new") and also misses < > in places.
>
> Some new methods use a different brace position from the existing
> code, such as ArrayUtils.toArray(), Validate.matchesPattern(),
> Validate.exclusiveBetween()...
>
> Some new code isn't explicit about null handling, such as
> AnnotationUtils, CharSequenceUtils, Validate.exclusiveBetween()...
>
> Some new methods don't have an @since, such as Validate.notBlank(),
> Validate.exclusiveBetween()...
>
> StringUtils is now an odd mixture of methods that accept a
> CharSequence and ones that don't. Looking at it, I'd prefer to see
> CharSequenceUtils added to, and StringUtils methods just deal with
> Strings (A CharSequence might be mutable, so it has a different set of
> implications when writing code using it). But if that isn't OK, then
> it would be better to see everything in StringUtils take a
> CharSequence.
>
> ToStringStyle doesn't have a serialization version ID.
>
> While we've moved away from NullArgumentException, I suspect it may be
> reasonably widely used.
>
> DateUtils has added a new MODIFY int enum, rather than using a real
> enum. Nor has the existing RANGE int enum been converted
>
> The JavaVersion name field is not used.
>
> ObjectUtils.firstNonNull() differs from Google Guava in that it can
> return null. This is probably OK, but should be checked.
>
> Range is only thread safe if the objects held inside are thread safe 
> (javadoc).
>
> Range.containsRange() might be better named containsAll()
> Range.overlapsRange might be better named overlaps()
>
> Public constants on StringEscapeUtils do not have javadoc.
>
> The StringUtils.concat methods duplicate the existing join methods.
>
> There are a number of TODOs in the code that might need addressing.
>
> The migration guide exceptions section is missing a header.
>
>
> Hope some of this helps (!)
> Stephen
>
>
> On 3 March 2011 07:39, Henri Yandell  wrote:
>> Looking to release 3.0; there's not been a lot of JIRA activity and
>> it's 9 months or so since we released the beta.
>>
>> Downloads:
>>
>>  http://people.apache.org/~bayard/commons-lang3-RC1/
>>
>> Maven repo entry:
>>
>>  http://people.apache.org/~bayard/commons-lang3-RC1/maven/
>>
>> Website:
>>
>>  http://people.apache.org/~bayard/commons-lang3-RC1/site/
>>
>> Tag:
>>
>>  https://svn.apache.org/repos/asf/commons/proper/lang/tags/LANG_3_0_RC1
>>
>> [ ] +1
>> [ ] -1, because:
>>
>>
>> Thanks,
>>
>> Hen
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

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

Re: [VOTE] Release Commons Lang 3.0 (RC1)

[Henri Yandell]

Going through each.

On Thu, Mar 3, 2011 at 3:59 AM, Stephen Colebourne  wrote:
> I'm not overly enthused about some of the changes, but since I've not
> been paying attention its difficult for me to vote/block. Anyway here
> is my review:
>
> ArrayUtils.hashCode() has been removed, but it had different
> functionality to Arrays.hashCode wrt nested arrays.
>
>        Object[] arrayA = new Object[] {new boolean[] {true, false},
> new int[] {6, 7}};
>        Object[] arrayB = new Object[] {new boolean[] {true, false},
> new int[] {6, 7}};
>        assertEquals(true, Arrays.hashCode(arrayB) == Arrays.hashCode(arrayA));

Fair. Should be brought back in.

> I don't love the new Pair class. We have an interface based version
> here at OpenGamma to allow primitive implementations for performance.
> I might be able to get our code released if there was interest.

Tbh, ENOCARE :) I'm happy to see there's good discussion, but I only
ever needed one when porting Scheme tutorials to Java for amusement.

> ArrayUtils.toArray() javadoc has example code that won't compile
> (missing "new") and also misses < > in places.

Jörg fixed.

> Some new methods use a different brace position from the existing
> code, such as ArrayUtils.toArray(), Validate.matchesPattern(),
> Validate.exclusiveBetween()...

Jörg fixed.

> Some new code isn't explicit about null handling, such as
> AnnotationUtils, CharSequenceUtils, Validate.exclusiveBetween()...

Do you mean that the javadoc doesn't explicitly say what happens when
null is passed in?

> Some new methods don't have an @since, such as Validate.notBlank(),
> Validate.exclusiveBetween()...

Note; action item to go through the hack-Clirr and cross-reference
missing @sinces.

> StringUtils is now an odd mixture of methods that accept a
> CharSequence and ones that don't. Looking at it, I'd prefer to see
> CharSequenceUtils added to, and StringUtils methods just deal with
> Strings (A CharSequence might be mutable, so it has a different set of
> implications when writing code using it). But if that isn't OK, then
> it would be better to see everything in StringUtils take a
> CharSequence.

By design :(

The aim is that everything in StringUtils that can reasonably take a
CharSequence does; but to move a method to CharSequenceUtils simply
because we made it use a higher interface is silly.

Given the 1 method in CharSequenceUtils, discussing this makes me tend
towards shoving it in the bloated StringUtils class.

> ToStringStyle doesn't have a serialization version ID.

Presumably hasn't had one for a long time :) It's an abstract class -
it feels to me that it doesn't need to have a serialization version
ID.

> While we've moved away from NullArgumentException, I suspect it may be
> reasonably widely used.

People can make the case to add it back in :) Having Exceptions that
weren't related to our actual API turned into an exercise in navel
gazing.

> DateUtils has added a new MODIFY int enum, rather than using a real
> enum. Nor has the existing RANGE int enum been converted

Good point.

I'm still very tempted to pull the entire package. It would be fun to
port/submit the code into Joda Time and see what you parts you find
acceptable there.

> The JavaVersion name field is not used.

It is in spirit :) Pretend there's a map there with the name as the
key. Then pretend that I unrolled the map to have a simple String case
statement :)

Or ignore that and I should probably add a toString that will make it used.

> ObjectUtils.firstNonNull() differs from Google Guava in that it can
> return null. This is probably OK, but should be checked.

Six of one, half a dozen of the other. I'm not sure if returning null
or throwing NPE has any specific value over the other.

> Range is only thread safe if the objects held inside are thread safe 
> (javadoc).

Added.

> Range.containsRange() might be better named containsAll()
> Range.overlapsRange might be better named overlaps()

I've gone with containsAll() and overlapsWith().

> Public constants on StringEscapeUtils do not have javadoc.

Reported as LANG-682 (as I have to do work now).

> The StringUtils.concat methods duplicate the existing join methods.

LANG-683.

> There are a number of TODOs in the code that might need addressing.

I've gone through these and none have been critical. Please feel free
to call them out if they are (the website has a todo report).

> The migration guide exceptions section is missing a header.

Fixed.

> Hope some of this helps (!)

Very much so. Stick around a bit more :)

Hen

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

Re: [codec] Error in the Caverphone implemention

[Henri Yandell]

Is there a need for 1.0?

On Thu, Mar 3, 2011 at 4:38 AM, Gary Gregory  wrote:
> Any though on splitting the class into two subclasses. One for cav
> 1.0, the other for 2.0?
>
> Gary
>
> On Mar 3, 2011, at 1:52, Henri Yandell  wrote:
>
>> Thanks Martin and Gary - sorry for my screwup.
>>
>> Very happy that you found the Caverphone code however Martin :)
>>
>> Hen
>>
>> On Tue, Mar 1, 2011 at 9:59 AM, Gary Gregory  wrote:
>>> The fix is in SVN and scheduled for inclusion in the upcoming Codec 1.5
>>> release.
>>>
>>> Thank you,
>>> Gary
>>>
>>> On Tue, Mar 1, 2011 at 6:05 AM, Martin Nybo Andersen  wrote:
>>>
>>>> Hi,
>>>>
>>>> On Mon, 28 Feb 2011, Matt Benson wrote:
>>>>
>>>>  Finally, given the fact that we are discussing patches (which have to
>>>>> be granted IP blah blah blah anyway) as well as the fact that you are
>>>>> not subscribed to the developer list, this exchange should be
>>>>> conducted in JIRA.
>>>>>
>>>>> Matt
>>>>>
>>>>
>>>> I wrote the mail to raise a flag. You saw it, which was my intention. I'm
>>>> happy now.
>>>>
>>>> To create a jira account for this minor bug seems to be overkill for me.
>>>> Remember that the harder it is to report a bug, the fewer bugs will be
>>>> reported.
>>>>
>>>> I am not subscribed to this mailing list for the same reason.
>>>>
>>>> What you do with the bug now, is for you to decide.
>>>>
>>>>
>>>>> On Mon, Feb 28, 2011 at 10:04 AM, Gary Gregory 
>>>>> wrote:
>>>>>
>>>>>> Would you be able to include a unit test patch in your diff file?
>>>>>>
>>>>>
>>>> new Caverphone().encode("mbmb") currently returns "MMP111" while it
>>>> should return "MPM111".
>>>>
>>>>
>>>>>> Also, it seems that the examples from
>>>>>>
>>>>>> http://en.wikipedia.org/wiki/Caverphone
>>>>>>
>>>>>> do not match our code:
>>>>>>
>>>>>>            {"Lee", "L1"},
>>>>>>            {"Thompson", "TMPSN1"},
>>>>>>
>>>>>>
>>>> These Caverphones seems to be version 1. Version 2 which is implemented in
>>>> apache.commons uses 10-letter-codes.
>>>>
>>>>  Hm...
>>>>>>
>>>>>> Thank you,
>>>>>> Gary
>>>>>>
>>>>>> On Mon, Feb 28, 2011 at 8:13 AM, Martin Nybo Andersen >>>>>> wrote:
>>>>>>
>>>>>>  Hi,
>>>>>>>
>>>>>>> I've found an error in the Caverphone language codec.
>>>>>>>
>>>>>>> According to the specs at page 2 line 6:
>>>>>>> "If the name ends with mb make it m2".
>>>>>>>
>>>>>>> Apparently is has been interpreted as:
>>>>>>> "If the name _starts_ with mb make it m2".
>>>>>>>
>>>>>>> The attached patch will fix it.
>>>>>>>
>>>>>>> Please CC me, as I'm not subscribed.
>>>>>>>
>>>>>>
>>>>
>>>> Regards,
>>>> Martin Nybo Andersen
>>>
>>>
>>>
>>>
>>> --
>>> Thank you,
>>> Gary
>>>
>>> http://garygregory.wordpress.com/
>>> http://garygregory.com/
>>> http://people.apache.org/~ggregory/
>>> http://twitter.com/GaryGregory
>>>
>

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

Re: [codec] Error in the Caverphone implemention

[Henri Yandell]

Heh - pretty sure the 2.0/1.0 bit is me :)

Given I'd written a 1.0 impl first, I think I simply didn't want to
lose the code.

If you think there's value in both, then I'm all for it. I think at
the time I was implementing something fun and didn't know if 2.0 was a
replacement for 1.0 or not. I didn't know if anyone would even use it,
so I'm very happy Martin answered that one :)

Hen

On Thu, Mar 3, 2011 at 10:44 PM, Gary Gregory  wrote:
> I am not a SME in Caverphone land but I do see in the code comments
> that guide through commenting this line in and that line out to toggle
> between both versions. I would never toggle between versions like that
> nor would I recommend it. This lead me to propose the two classes. In
> addition, it could be useful to provide both versions for programs
> that compare various algorithms. I've seen a couple of papers that
> produce all sorts of stats for different codecs. Reading papers
> recently on cologne and cavedphone while looking for test data is
> where I found such stats for example.
>
> Gary
>
> On Mar 4, 2011, at 1:18, Henri Yandell  wrote:
>
>> Is there a need for 1.0?
>>
>> On Thu, Mar 3, 2011 at 4:38 AM, Gary Gregory  wrote:
>>> Any though on splitting the class into two subclasses. One for cav
>>> 1.0, the other for 2.0?
>>>
>>> Gary
>>>
>>> On Mar 3, 2011, at 1:52, Henri Yandell  wrote:
>>>
>>>> Thanks Martin and Gary - sorry for my screwup.
>>>>
>>>> Very happy that you found the Caverphone code however Martin :)
>>>>
>>>> Hen
>>>>
>>>> On Tue, Mar 1, 2011 at 9:59 AM, Gary Gregory  
>>>> wrote:
>>>>> The fix is in SVN and scheduled for inclusion in the upcoming Codec 1.5
>>>>> release.
>>>>>
>>>>> Thank you,
>>>>> Gary
>>>>>
>>>>> On Tue, Mar 1, 2011 at 6:05 AM, Martin Nybo Andersen  
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On Mon, 28 Feb 2011, Matt Benson wrote:
>>>>>>
>>>>>>  Finally, given the fact that we are discussing patches (which have to
>>>>>>> be granted IP blah blah blah anyway) as well as the fact that you are
>>>>>>> not subscribed to the developer list, this exchange should be
>>>>>>> conducted in JIRA.
>>>>>>>
>>>>>>> Matt
>>>>>>>
>>>>>>
>>>>>> I wrote the mail to raise a flag. You saw it, which was my intention. I'm
>>>>>> happy now.
>>>>>>
>>>>>> To create a jira account for this minor bug seems to be overkill for me.
>>>>>> Remember that the harder it is to report a bug, the fewer bugs will be
>>>>>> reported.
>>>>>>
>>>>>> I am not subscribed to this mailing list for the same reason.
>>>>>>
>>>>>> What you do with the bug now, is for you to decide.
>>>>>>
>>>>>>
>>>>>>> On Mon, Feb 28, 2011 at 10:04 AM, Gary Gregory 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Would you be able to include a unit test patch in your diff file?
>>>>>>>>
>>>>>>>
>>>>>> new Caverphone().encode("mbmb") currently returns "MMP111" while it
>>>>>> should return "MPM111".
>>>>>>
>>>>>>
>>>>>>>> Also, it seems that the examples from
>>>>>>>>
>>>>>>>> http://en.wikipedia.org/wiki/Caverphone
>>>>>>>>
>>>>>>>> do not match our code:
>>>>>>>>
>>>>>>>>            {"Lee", "L1"},
>>>>>>>>            {"Thompson", "TMPSN1"},
>>>>>>>>
>>>>>>>>
>>>>>> These Caverphones seems to be version 1. Version 2 which is implemented 
>>>>>> in
>>>>>> apache.commons uses 10-letter-codes.
>>>>>>
>>>>>>  Hm...
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> Gary
>>>>>>>>
>>>>>>>> On Mon, Feb 28, 2011 at 8:13 AM, Martin Nybo Andersen >>>>>>>> wrote:
>>>>>>>>
>>>>>>>>  Hi,
>>>>>>>>>
>>>>>>>>> I've found an error in the Caverphone language codec.
>>>>>>>>>
>>>>>>>>> According to the specs at page 2 line 6:
>>>>>>>>> "If the name ends with mb make it m2".
>>>>>>>>>
>>>>>>>>> Apparently is has been interpreted as:
>>>>>>>>> "If the name _starts_ with mb make it m2".
>>>>>>>>>
>>>>>>>>> The attached patch will fix it.
>>>>>>>>>
>>>>>>>>> Please CC me, as I'm not subscribed.
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Martin Nybo Andersen
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thank you,
>>>>> Gary
>>>>>
>>>>> http://garygregory.wordpress.com/
>>>>> http://garygregory.com/
>>>>> http://people.apache.org/~ggregory/
>>>>> http://twitter.com/GaryGregory
>>>>>
>>>
>

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

Re: [lang3] Pair

[Henri Yandell]

On Fri, Mar 4, 2011 at 3:41 AM, Stephen Colebourne  wrote:
> I now have authoristion from OpenGamma to discuss adding a Pair class
> to [lang] based on our internal classes. If necessary a CCLA can be
> signed, although since we are not necessarily importing the OpenGamma
> classes as is and I'd be writing code in [lang3] with my Apache hat
> on, the CCLA might not be needed. I can also code it in work time :-)

CCLA up to you and your company. You've signed a CLA so no concerns on my part.

> The main goal would be either an abstract class or an interface for
> Pair. We chose an abstract class so that it could have factory
> methods:
>
>  Pair p = Pair.of("Foo", 6);
>
> It also allowed more control over the immutability of Pair (although
> because its abstract and holds references to any object, immutability
> cannot be guaranteed).
>
> We then have other concrete classes:
> - ObjectsPair - two generified objects
> - DoublePair - two double
> - IntDoublePair - int and double
> - LongDoublePair - long and double
> - IntObjectPair - int and generified object
> - LongObjectPair - long and generified object
>
> Clearly there are many more possible combinations, but some make less
> sense than others. (Booleans don't waste space, as they are a
> singleton reference, short/float are rarely used)
>
> Beyond this, there are some standard comparators.
>
> Design wise, we implement Map.Entry (makes sense). The primitive
> classes implement primitive map entry interfaces from another library,
> but that wouldn't make sense here. They are comparable and
> serializable (again, one reason for an abstract class).
>
> We name our elements "first" and "second".
>
> The elements are available by methods (for generics) or as public
> final variables from the concrete classes (not the abstract one). The
> methods are getFirst(), getSecond() plus getKey() and getValue() for
> Map compatibility.
>
> The pairs are implemented as immutable. I saw someone mention the
> possibility of a mutable pair, so perhaps we consider that.
>
> I don't want this to be a long process of design or implementation! If
> there isn't rapid consensus, I'd suggest either shipping [lang3] with
> or without the existing class.
>
> Opinions?

Charge along with your ideas, once other topics are refined we can
branch 3.x off to 3.0 and refine that there while Pair continues if
need be.

I want to change the release style of Lang - I want to release every
couple of issues once we get Lang 3.0 out. Or every month. I want
3.0.68 to exist :) Missing the 3.0 date shouldn't be an issue at all
unless it's a backwards compat issue.

Hen

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

Re: svn commit: r1077934 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/time/DateUtils.java

[Henri Yandell]

On Fri, Mar 4, 2011 at 9:19 AM, Stephen Colebourne  wrote:
> On 4 March 2011 17:15, sebb  wrote:
>> On 4 March 2011 13:30,   wrote:
>>> Log:
>>> Document mutability of UTC constant, which isn't ideal
>
>> AFAICT, it's not used within Lang3 - so why don't we just delete it ?
>>
>> Does it really offer much benefit, given the drawback of malicious or
>> accidental corruption?
>
> I'm strongly in favour of replacing this with either removing it or
> adding a static method that creates a new instance each time it is
> called.

+1.

I'm all for removing things. I don't see much harm from making this a
static method that creates a new instance though, I can see the vague
value in the feature.

Hen

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

Re: [lang3] Pair

[Henri Yandell]

+1 for you to go ahead and put something in. We can pull if it feels
that everything else is ready and Pair et al are not there yet.

Hen

On Sat, Mar 5, 2011 at 11:28 AM, Stephen Colebourne
 wrote:
> On 4 March 2011 18:35, Matt Benson  wrote:
>> I agree that it would be nice to do whatever we're going to do
>> quickly, and ship with *something*.  On the other hand, I don't want
>> to ship the existing class without consensus on design, only to give
>> ourselves (and users) headaches trying to replace it in a subsequent
>> release.
>
> Since the existing Pair class can't be altered after the fact, we need
> to ship without it, or code this up quickly.
>
>> I also had the thought that the abstract class would be necessary for
>> the factory methods.  It doesn't seem important, but I'd really like
>> to be able to say Pair.of(X, Y).  Semantically it'd also be nice to be
>> able to use fields on the immutable variety of Pair (it's perhaps
>> debatable in light of JIT whether the final field access yields better
>> performance, so I won't address it--but it *looks* faster :P ), while
>> still requiring the client to know as little as possible about the RT
>> type of the Pair.  Is it possible to accomplish all these things?
>>
>> abstract class Pair implements Map.Entry {
>>  abstract L getLeft();
>>  abstract R getRight();
>>  final L getKey() { return getLeft(); }
>>  final R getValue() { return getRight(); }
>>  static  ImmutablePair of(L, R) {}
>> }
>>
>> class ImmutablePair extends Pair {
>>  final L left;
>>  final R right;
>>  ImmutablePair(L left, R right) { this.left = left; this.right = right; }
>>  L getLeft() { return left; }
>>  R getRight() { return right; }
>>  static  ImmutablePair of(L, R) {}
>> }
>>
>> class MutablePair extends Pair {
>>  private L left;
>>  private R right;
>>
>>  MutablePair(L left, R right) { setLeft(left); setRight(right); }
>>  L getLeft() { return left; }
>>  setLeft(L left) { this.left = left; }
>>  R getRight() { return right; }
>>  setRight(R right) { this.right = right; }
>>  static  MutablePair of(L, R) {}
>> }
>
> These class outlines are very similar to what I would propose from
> OpenGamma. I'll need to check on Monday, but with those three classes
> as they are above, I'd probably be happy.
>
>> In the examples above I continue to use the left/right idiom for
>> reasons of inertia; in the end, I don't *really* care.  It seems
>> examples abound of the various proposed paired names in other
>> programming contexts, so this becomes a simple matter of taste and/or
>> majority rules.  Personally I prefer left/right as there is less
>> connotation of priority given either member of the pair as (IMO) in
>> the case of first/second.
>
> Typically, the order is of some significance, as the generics force you to 
> care.
>
>> If we want to extend ImmutablePair for the wrapper types (it wouldn't
>> seem to make sense to provide access to the primitive equivalent
>> values in the MutablePair variety), where does it end?  If we provide
>> any such pair types, IMO we should use some predictable rule to
>> define, for a given wrapper type, what combinations are available,
>> e.g.:
>>
>> * X Double
>> * X Boolean
>> * X Object
>> * X self
>> * X * ?
>
> I think that [lang] could probably stop with the three classes above,
> and leave primitive implementations to others.
>
> BTW, Pair is the right class name given how I've seen it discussed in
> various places.
>
> Stephen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

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

Re: [VOTE] Release Commons Lang 3.0 (RC1)

[Henri Yandell]

On Sat, Mar 5, 2011 at 8:46 AM, Oliver Heger
 wrote:
> Two minor points from my side:
>
> - There are still many checkstyle errors in the current code base.

Can be improved but nothing felt hugely critical. A large amount are
lines greater than 120 chars. Looks like SystemUtils has been
formatted for 135 chars and creates a lot of the warnings.

A fair number of generic parameter javadoc items.

Nothing I'd want to hold a release up for; but anyone can jump in and
improve. I've added javadoc for StringEscapeUtils and EntityArray as
they felt like large ones.

> - Just a proposal: There are some translators in the new translate package
> which can be configured with a range of the codes to be processed. Would it
> make sense to use the Range class for this purpose? Then configuration could
> be more flexible (because multiple ranges could be specified), and there
> would probably be less duplicate code for checking the ranges.

Very interesting.

Also makes me wonder if Range should support the notion of
Range.above, Range.below and Range.outside in addition to
Range.between and Range.is. That change the API from:

  UnicodeEscaper.between(x, y)

to:

  new UnicodeEscaper(Range.between(x,y))
  new UnicodeEscaper(Range.above(y))
  new UnicodeEscaper(Range.below(x))
  new UnicodeEscaper(Range.outsideOf(x,y))

For the translators; sounds great. I'm trying to remember if I hit
problems introducing the feature of either an open-ended Range, or an
inverted Range. Looking at LANG-551, it looks like I tried to
introduce the inverted Range notion (outsideOf) so that I could merge
in CharRange, and it never really worked.

Worth trying again I think.

Hen

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

Re: [VOTE][SITE] Release Commons Skin 3 and Commons Parent 19

[Henri Yandell]

Should we be claiming trademark on 'Commons'?

Like Incubator & Attic it seems like something we want to continue
encouraging as a de facto standard instead of subjecting to trademark
protection.

Hen

On Mon, Mar 7, 2011 at 12:47 PM, sebb  wrote:
> I think the time has come to formally vote on the updates to Commons
> Skin and Commons Parent.
>
> Maven artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecommons-008/org/apache/commons/
>
> SVN
> https://svn.apache.org/repos/asf/commons/proper/commons-skin/tags/commons-skin-3-RC2/
> and
> https://svn.apache.org/repos/asf/commons/proper/commons-parent/tags/commons-parent-19-RC2/
>
> Commons Skin 3 changes
> ===
> - commons parent 5 => 18
> - added support for code prettify
> - site.css now uses relative url for referencing css files, so offline
> sites work better
> - added template to support trademark footer; also supports
> $relativePath resolution; adds TM overlay support; allows absolute
> URLs in banner elements
>
> Commons Parent 19 changes
> ==
> - Apache Parent Pom 7=> 9
> - maven-antrun-plugin 1.3 => 1.5
> - antrun config: change deprecated  to 
> - site plugin 2.0.1 => 2.2
> - surefire 2.7.1 => 2.7.2
> - javadoc 2.5 => 2.7
> - add AL header to site.xml
> - use local copy of commons-logo, rather than linking to commons.a.o
> - always use absolute link for http://commons.a.o/
> - commons skin 2=>3
> - added prettify css/javascript to improve source code formatting
> - license now points to http://www.apache.org/licenses/ as per
> branding guidelines
> - synchronise common menu items with commons-site
> - moved ApacheCon logo under ASF menu, and made it clickable
> - added trademark references to page footers
> - added TM symbol overlays to banner images
>
> Note that Commons Parent depends on Commons Skin 3.
>
> Commons Skin 3 based on RC2
> ===
>
> [ ] +1
> [ ] -1, because:
>
> Commons Parent 19 based on RC2
> ==
>
> [ ] +1
> [ ] -1, because:
>
> Please test the skin and vote!
>
> Thanks!
>
> Vote will remain open for at least 72 hours.
>
> -
> 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] Apache Commons as a sponsor for OGNL to join the Incubator

[Henri Yandell]

+1.

On Tue, Mar 8, 2011 at 5:17 AM, Jochen Wiedmann
 wrote:
> +1
>
> If the project is indeed used by Struts and Tapestry (as claimed in
> the proposal), then I see no reason for objecting.
>
>
> On Tue, Mar 8, 2011 at 12:58 PM, Simone Tripodi
>  wrote:
>> Hi all PMCs,
>> I prepared the OGNL[1] proposal to be submitted to the ASF incubator,
>> I already discussed with involved people and the original author and
>> we all agreed Commons should be the best place for OGNL where living.
>> Some of them are Struts PMC members, they also asked on their private
>> MLs and they agreed that Commons would be the best.
>> So, I'm here to call for a vote for Commons PMC be the OGNL Sponsor,
>> please cast your votes.
>>
>> [ ] +1
>> [ ] +/- 0
>> [ ] -1, because...
>>
>> Many thanks in advance, have a nice day,
>> Simo
>>
>> [1] http://wiki.apache.org/incubator/OGNLProposal
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
>
> --
> I Am What I Am And That's All What I Yam (Popeye)
>
> -
> 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: Trademakrs and logos. WAS beanutils commit msg...

[Henri Yandell]

On Sat, Mar 12, 2011 at 10:03 AM, Phil Steitz  wrote:
> On 3/12/11 10:41 AM, Mark Thomas wrote:
>> On 12/03/2011 15:52, Phil Steitz wrote:
>>> On 3/12/11 8:45 AM, sebb wrote:
 On 12 March 2011 04:20, Phil Steitz  wrote:
> I thought we had agreed that we are not going to do this, i.e.,
> maintain that commons-foo is *not* an ASF trademark.  Otherwise, we
> need to be prepared to defend all of these "trademarks" which makes
> no sense to me personally.
 I thought you just meant that we should not claim "Commons" as a
 trademark, rather than not claiming any "Commons YYY" names as marks.

 However whatever happens re Commons, we still need to claim trademark
 on Apache at the bottom of our pages (so most of the work was needed
 anyway).

 I don't really mind what is decided, so long as it is agreed with 
 @Trademarks.
>>> OK.  I just asked on board@.  They may toss it over to trademarks,
>>> but I personally see this as first a Commons decision, which the
>>> Board could require us to change.
>>>
>>> Please anyone else chime in with different opinions.  I want to make
>>> sure I am not misrepresenting our views.
>> I think we would have difficulty claiming "Commons" as a trademark.

I don't care about the difficulty. I do think we want the software
world to use the word, similar to Incubator, Labs, "Software
Foundation" and Attic; and restricting it is not in our interest.
Whether that means claim-and-broadly-license or not-claim, I would
leave to trademarks@/legal counsel.

I realize that I earlier said 'claiming Commons bad' as well; I was
jumping to a solution instead of letting Shane et al deal with our
requirement which is de-facto standard.

>> I think we should be claiming/protecting:
>> - Apache Commons
>> - Apache Commons Foo
>> - Commons Foo
> Why, exactly?

The foundation's trademark direction has been to claim everything it can.

> And why do we think we *can* claim, for example, "Commons Email?"

Seems to me that it's claimable. We are currently using the phrase, as
a compound mark it isn't a common word (imo) even if it is made up of
two common words and it's in accordance with foundation strategy.

Hen

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

Re: Trademakrs and logos. WAS beanutils commit msg...

[Henri Yandell]

On Sun, Mar 13, 2011 at 10:52 AM, Phil Steitz  wrote:
> On 3/13/11 10:28 AM, Mark Thomas wrote:
>> On 13/03/2011 16:45, Phil Steitz wrote:
>>> On Mar 13, 2011, at 1:24 AM, Mark Thomas  wrote:
 On 12/03/2011 18:03, Phil Steitz wrote:
> On 3/12/11 10:41 AM, Mark Thomas wrote:
>> On 12/03/2011 15:52, Phil Steitz wrote:
>> 
>>> Please anyone else chime in with different opinions.  I want to make
>>> sure I am not misrepresenting our views.
>> I think we would have difficulty claiming "Commons" as a trademark.
>>
>> I think we should be claiming/protecting:
>> - Apache Commons
>> - Apache Commons Foo
>> - Commons Foo
> Why, exactly?
 Because I don't want BigCorp to be able to create a product called
 "Apache Commons Math". If we don't protect our marks then we have no way
 of stopping abuse.
>>> Do you honestly think that the probability of that is distinguishable from 
>>> 0 as a double?
>> For all Commons components, over their potential lifetime, yes I think
>> the probability is a lot closer to 1 than 0.
>>
>>> Seriously, I have a hard time envisioning this, and an even harder time 
>>> convincing myself that we should be spending precious volunteer hours 
>>> making changes throughout the commons sites to mitigate this risk.  
>>> Especially when these changes may give the wrong impression to some users / 
>>> potential volunteers.
>> I don't see how claiming our trademarks can give the wrong impression.
> The impression that we are a commercial entity, or that we are
> representing the interests of other commercial entities.  Most
> people see trademarks as only meaningful in commercial settings.  We
> have a more sophisticated view @apache that views trademarks as
> meaningful outside of commercial use, or more precisely as limiting
> commercial use of the names.  My admittedly minority view is that
> aggressively "claiming marks" does not help our public image.
>
> I will shut up about this now and we can proceed with the changes,
> since this is consistent with ASF policy and we do not have
> consensus to challenge that policy.

It depends on component.

We should always claim "Apache Commons XYZ". Seems weak in terms of
energy given that we claim "Apache", but presumably there are good
reasons why "Apache Commons XYZ" gives us more value/power/something
than Apache on its own does.

For a unique name, for example, Sanselan, we should state our claim of:

  "Apache Commons Sanselan"
  "Commons Sanselan"
  "Sanselan"

At least I'm assuming that trademarks@ will want to keep a name like
'Sanselan' as close to its chest as possible.

For a non-unique name, for example, Math, we should state our claim of:

  "Apache Commons Math".

[where claiming 'Math' is ludicrous, and claiming 'Commons Math' is
only a shade less ludicrous].

This does assume that we're not claiming 'Commons'. If we claim
'Commons', then 'Commons Math' is a direct follow-on; but claiming
'Commons' is against our aims imo.

On the technical side - we can't do this in a generic commons-build
way imo. We have to split our names into 'hug close' and 'ludicrous'
and do footers accordingly.

Hen

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

[lang] Remaining work

[Henri Yandell]

Here's the remaining list that I know of for 3.0:

1) The thread on Pair appears to have quietened down and there's code
in svn. Considering this [DONE].

2) Oliver proposed the translators be modified to accept a Range as
the API. Might be possible.

3) Stephen pointed out there were methods with @since 3.0 missing.
I've gone through and fixed a lot of these using the Clirr report from
2.6. One pain is that we don't have the @since 2.5 and @since 2.6
items in here. So a minor action item to look at the 2.6 source and
copy both of those sets of @sinces over.

4) Stephen urged that we revisit StringUtils to see what else can move
to CharSequence.

5) Stephen recommended that CharSequenceUtils move into StringUtils.
This seems fair, CharSequenceUtils is never going to get a lot of
methods unless we move half of StringUtils out and make it feel very
odd. [DONE].

6) Stephen reported that the DateUtils UTC constant isn't threadsafe
(thus copied to DateFormatUtils) and that we should look to remove it.


So 2 out of 6 done. 4 to go.

Hen

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

[lang] CharSequenceUtils resurrection? [Was: Remaining work]

[Henri Yandell]

On Tue, Mar 15, 2011 at 9:39 PM, Henri Yandell  wrote:

> 4) Stephen urged that we revisit StringUtils to see what else can move
> to CharSequence.
>
> 5) Stephen recommended that CharSequenceUtils move into StringUtils.
> This seems fair, CharSequenceUtils is never going to get a lot of
> methods unless we move half of StringUtils out and make it feel very
> odd. [DONE].

So having done #5, and working on #4, I'm starting to come up with a
bunch of methods that might make sense on CharSequenceUtils.

Basically it's a set of methods on java.lang.String that are being
implemented to support CharSequence. The first step is to check if the
CharSequence is a String; if so then optimize and use the
java.lang.String code. Otherwise use a basic implementation built on
top of the CharSequence API. They're currently living at the end of
the StringUtils class, but I'm leaning towards making them their own
class. CharSequenceUtils, or is there a better name?

I'd also appreciate feedback on the current changes in case it's felt
I'm reaching too much to support CharSequence as an API; I'm 20 of 76
unique method names along :)

Hen

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

Re: [lang] CharSequenceUtils resurrection? [Was: Remaining work]

[Henri Yandell]

Note the .toString() on the end.

Hen

On Thu, Mar 17, 2011 at 9:08 AM, Gary Gregory  wrote:
> Looking at:
>
>    public static String right(CharSequence seq, int len)
>
> I wonder why it is not:
>
>    public static CharSequence right(CharSequence seq, int len)
>
> You think that would break call sites is why. But when I look at the impl,
> the last line is:
>
>    return StringUtils.subSequence(seq, seq.length() - len).toString();
>
> Where subSequence is typed to return a CharSequence.
>
> Does the compiler convert the CharSequence to a String? How does that even
> compile?
>
> Gary
>
> On Thu, Mar 17, 2011 at 3:08 AM, Henri Yandell  wrote:
>>
>> On Tue, Mar 15, 2011 at 9:39 PM, Henri Yandell  wrote:
>>
>> > 4) Stephen urged that we revisit StringUtils to see what else can move
>> > to CharSequence.
>> >
>> > 5) Stephen recommended that CharSequenceUtils move into StringUtils.
>> > This seems fair, CharSequenceUtils is never going to get a lot of
>> > methods unless we move half of StringUtils out and make it feel very
>> > odd. [DONE].
>>
>> So having done #5, and working on #4, I'm starting to come up with a
>> bunch of methods that might make sense on CharSequenceUtils.
>>
>> Basically it's a set of methods on java.lang.String that are being
>> implemented to support CharSequence. The first step is to check if the
>> CharSequence is a String; if so then optimize and use the
>> java.lang.String code. Otherwise use a basic implementation built on
>> top of the CharSequence API. They're currently living at the end of
>> the StringUtils class, but I'm leaning towards making them their own
>> class. CharSequenceUtils, or is there a better name?
>>
>> I'd also appreciate feedback on the current changes in case it's felt
>> I'm reaching too much to support CharSequence as an API; I'm 20 of 76
>> unique method names along :)
>>
>> Hen
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
>
>
> --
> Thank you,
> Gary
>
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>

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

Re: [lang] CharSequenceUtils resurrection? [Was: Remaining work]

[Henri Yandell]

Yeah, I didn't stress the "will want a name change if made public"
enough in the comment higher up in the file. I wanted a style that
wasn't overlapping with the public StringUtils classes; that one is
sequenceToString more to keep in sync with the other methods than
because it's a good name.

It's a bad method anyway - calling .toString() is the one method that
is fine as a String will merely return itself.

Hen

On Thu, Mar 17, 2011 at 8:58 AM, Gary Gregory  wrote:
> Minor nit:
>
> String sequenceToString(CharSequence cs)
>
> should be:
>
> String toString(CharSequence cs)
>
> because the we do not need to add the method arg type to the method name. If
> we did, we should use:
>
> String charSequenceToString(CharSequence cs)
>
> which I do not like.
>
> Gary
>
> On Thu, Mar 17, 2011 at 3:08 AM, Henri Yandell  wrote:
>>
>> On Tue, Mar 15, 2011 at 9:39 PM, Henri Yandell  wrote:
>>
>> > 4) Stephen urged that we revisit StringUtils to see what else can move
>> > to CharSequence.
>> >
>> > 5) Stephen recommended that CharSequenceUtils move into StringUtils.
>> > This seems fair, CharSequenceUtils is never going to get a lot of
>> > methods unless we move half of StringUtils out and make it feel very
>> > odd. [DONE].
>>
>> So having done #5, and working on #4, I'm starting to come up with a
>> bunch of methods that might make sense on CharSequenceUtils.
>>
>> Basically it's a set of methods on java.lang.String that are being
>> implemented to support CharSequence. The first step is to check if the
>> CharSequence is a String; if so then optimize and use the
>> java.lang.String code. Otherwise use a basic implementation built on
>> top of the CharSequence API. They're currently living at the end of
>> the StringUtils class, but I'm leaning towards making them their own
>> class. CharSequenceUtils, or is there a better name?
>>
>> I'd also appreciate feedback on the current changes in case it's felt
>> I'm reaching too much to support CharSequence as an API; I'm 20 of 76
>> unique method names along :)
>>
>> Hen
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
>
>
> --
> Thank you,
> Gary
>
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>

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

Re: [lang] CharSequenceUtils resurrection? [Was: Remaining work]

[Henri Yandell]

On Thu, Mar 17, 2011 at 12:08 AM, Henri Yandell  wrote:
> On Tue, Mar 15, 2011 at 9:39 PM, Henri Yandell  wrote:
>
>> 4) Stephen urged that we revisit StringUtils to see what else can move
>> to CharSequence.
>>
>> 5) Stephen recommended that CharSequenceUtils move into StringUtils.
>> This seems fair, CharSequenceUtils is never going to get a lot of
>> methods unless we move half of StringUtils out and make it feel very
>> odd. [DONE].
>
> So having done #5, and working on #4, I'm starting to come up with a
> bunch of methods that might make sense on CharSequenceUtils.
>
> Basically it's a set of methods on java.lang.String that are being
> implemented to support CharSequence. The first step is to check if the
> CharSequence is a String; if so then optimize and use the
> java.lang.String code. Otherwise use a basic implementation built on
> top of the CharSequence API. They're currently living at the end of
> the StringUtils class, but I'm leaning towards making them their own
> class. CharSequenceUtils, or is there a better name?
>
> I'd also appreciate feedback on the current changes in case it's felt
> I'm reaching too much to support CharSequence as an API; I'm 20 of 76
> unique method names along :)

Something occurred to me today. We're moving from String to
CharSequence in the API, but not thinking of the use case.

If I call:

StringUtils.toLowerCase(stringBuffer);

I'd argue that the likely style would be to modify the object being
passed in, not to return it (even if we could return a StringBuffer
instead of a new String). More specifically, if the CharSequence is
mutable, then mutate the passed in value, whereas if the CharSequence
is immutable, return a new version.

This makes me wonder if there's any value in moving to CharSequence.
Of the 5 subclasses, 4 of them are mutables:

CharBuffer, String (immutable), StringBuffer, StringBuilder and
our StrBuilder.

CharBuffer is only really appendable rather than wholly mutable;
unless optional methods are implemented.

So while this is in the abstract a good thing; I'm not convinced
converting to CharSequence will change anything. It'll still only get
called as a String because it returns String; but more importantly
because it doesn't modify in place.

It's tempting to either:

a) For every method, once CharSequence is there, return null if its a
known mutable and instead mutate the CharSequence.
b) For every method, once CharSequence is there, return a new string
AND for known mutables mutate the CharSequence.
c) Create a StringMutate class (by moving StringUtils) which modifies
the passed in and known mutable subclasses of CharSequence, then put
StringUtils on top of it and have it create a new StringBuilder each
time and pass it down to the class (or classes) with the real code.

Both b) and c) could be done in a later version. a) would be a big
change in functionality.

I'm liking c). We could add a super class above StrBuilder -
MutableCharSequence - and then implement three methods for every
method in StringUtils to support the three big mutables
(StringBuilder, StringBuffer + MutableCharSequence); or we could drop
StringBuffer. That increases the size of the class to 13,000 lines :)

Hen

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

Re: [lang] Why is a Range not a Pair?

[Henri Yandell]

I'm happy to go with the 'fails "is a kind of"'. The real answer is
because Range.java was coded before Pair.java iirc :)

Range is quite possibly going to also have ranges that are unbound on
one of the sides. It also might need to supported negated Ranges, i.e.
the range is from -inf->lower-bound & upper-bound->inf. One of the 3.0
feedback items was to move the translators over to a Range based API.

Hen

On Thu, Mar 17, 2011 at 9:03 AM, Gary Gregory  wrote:
> Why is a Range not a Pair?
>
> Because... is it fails the "is a kind of" OOD test?
>
> I could say that a range is a pair of bounds (an upper and lower bound.)
>
> I could argue that Range should subclass Pair. The question is: why are we
> NOT eating our own dog food?
>
> Which then brings me to the names of the bounds for Range: minimum and
> maximum, which IMO should be lowerBound and upperBound.
>
> Thoughts?
>
> --
> Thank you,
> Gary
>
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>

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

Re: [lang] CharSequenceUtils resurrection? [Was: Remaining work]

[Henri Yandell]

Agreed (apologies for the delay; life got, and is going to remain, very busy).

We should remove the CharSequence code I added. We should also review
the first batch of CharSequence changes.

I think it's fine to have this:

public int length(CharSequence seq)

I'll look into the removal if no one else gets to it - with a new baby
in the house that's going to depend very much on how calm she is.

Hen

On Fri, Mar 18, 2011 at 1:21 AM, Stephen Colebourne
 wrote:
> On 18 March 2011 03:56, Henri Yandell  wrote:
>> Something occurred to me today. We're moving from String to
>> CharSequence in the API, but not thinking of the use case.
>>
>> If I call:
>>
>>    StringUtils.toLowerCase(stringBuffer);
>>
>> I'd argue that the likely style would be to modify the object being
>> passed in, not to return it (even if we could return a StringBuffer
>> instead of a new String). More specifically, if the CharSequence is
>> mutable, then mutate the passed in value, whereas if the CharSequence
>> is immutable, return a new version.
>>
>> This makes me wonder if there's any value in moving to CharSequence.
>
> As I've probably said before, I think that most people are looking for
> a StringUtils operating on Strings and nulls. I personally never hold
> CharSequence as a variable, although obviously I use StringBuffer,
> StringBuilder and StrBuilder. But, I rarely have a CharSequence that
> is null - it doesn't make that much sense to do so as mutable strings
> are transient.
>
> The significant class IMO.is StrBuilder, which is [lang] owned. That
> is where all these utility methods go, Thus you can do:
>
> StrBuilder b = ...
> b.setLowerCase()
>
> If you need to operate on a StringBuffer or StringBuilder? Well,
> don't! [lang] says use StrBuilder. That was the original design, and
> frankly it still makes sense.
>
> Perhaps this is harsh and there is a role for a helper class for other
> CharSequence classes, but its one I personally would use rarely. Thats
> because null is rarely the issue with CharSequences, and it can easily
> be changed in most user code to a StrBuilder.
>
>> a) For every method, once CharSequence is there, return null if its a
>> known mutable and instead mutate the CharSequence.
> Horrible API
>
>> b) For every method, once CharSequence is there, return a new string
>> AND for known mutables mutate the CharSequence.
> Far from great (lots of code to create an abstraction that isn't abstract)
>
>> c) Create a StringMutate class (by moving StringUtils) which modifies
>> the passed in and known mutable subclasses of CharSequence, then put
>> StringUtils on top of it and have it create a new StringBuilder each
>> time and pass it down to the class (or classes) with the real code.
> Well, you could consider StrBuilder to be a form of StringMutate I
> suppose. But having StringUtils create and use a buffer for every
> method is very poor for performance. The performance really matters
> here, and thats why I think StringUtils should revert to solely
> Strings.
>
>> I'm liking c). We could add a super class above StrBuilder -
>> MutableCharSequence - and then implement three methods for every
>> method in StringUtils to support the three big mutables
>> (StringBuilder, StringBuffer + MutableCharSequence); or we could drop
>> StringBuffer. That increases the size of the class to 13,000 lines :)
>>
> There are many ways to cut this, for example, StrBuilder could be
> reworked to have the ability to update StringBuilder/StringBuffer:
>
> StringBuffer buf = ...
> StrBuilder view = StrBuilder.asViewOf(buf);
> view.setLowerCase()  // updates view and buf
>
> Internally, StrBuilder could
> (a) hold an Object and have a low level mutation plugin for char[],
> StringBuilder and StringBuffer
> (b) StrBuilder could store a StringBuilder rather than a char[],
> although I suspect that would hurt performance
> (c) Every StrBuilder method could end with resetLinkedView(), which
> would do buf.setLength(0);buf.append(toString()); Simple, but slow.
>
> It depends if there is the desire to support
> StringBuffer/StringBuilder or not.I suspect that (a) is the best
> choice.
>
> BTW, tearing CharSequence out of StringUtils sounds harsh. But I've
> been forced to tear generics out of systems late in the day when I've
> realised that they made the API worse not better. This seems like a
> parallel case here - we've been making StringUtils more complex, and
> its fundamentally not giving the desired benefits.
>
> Stephen
>
> -
> 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] CharSequenceUtils resurrection? [Was: Remaining work]

[Henri Yandell]

I've rolled the code back. Now I'm thinking the following are
candidates to roll back to String:

public static String stripAccents(CharSequence input) {
public static String capitalize(CharSequence cs) {
public static String uncapitalize(CharSequence cs) {

and the following are candidates to move to CharSequence:

public static boolean equalsIgnoreCase(String str1, String str2) {
public static int indexOf(String str, int searchChar) {
public static int indexOf(String str, int searchChar, int startPos) {
public static int indexOf(String str, String searchStr) {
public static int indexOf(String str, String searchStr, int startPos) {
public static int ordinalIndexOf(String str, String searchStr, int
ordinal) {
public static int indexOfIgnoreCase(String str, String searchStr) {
public static int indexOfIgnoreCase(String str, String searchStr,
int startPos) {
public static int lastIndexOf(String str, int searchChar) {
public static int lastIndexOf(String str, int searchChar, int startPos) {
public static int lastIndexOf(String str, String searchStr) {
public static int lastOrdinalIndexOf(String str, String searchStr,
int ordinal) {
public static int lastIndexOf(String str, String searchStr, int startPos) {
public static int lastIndexOfIgnoreCase(String str, String searchStr) {
public static int lastIndexOfIgnoreCase(String str, String
searchStr, int startPos) {
public static boolean contains(String str, int searchChar) {
public static boolean contains(String str, String searchStr) {
public static boolean containsIgnoreCase(String str, String searchStr) {
public static boolean containsWhitespace(String str) {
public static boolean containsAny(String cs, char[] searchChars) {
public static boolean containsAny(String cs, String searchChars) {
public static int indexOfAnyBut(String str, String searchChars) {
public static int indexOfAny(String str, String[] searchStrs) {
public static int lastIndexOfAny(String str, String[] searchStrs) {
public static int countMatches(String str, String sub) {
public static boolean startsWith(String str, String prefix) {
public static boolean startsWithIgnoreCase(String str, String prefix) {
public static boolean startsWithAny(String string, String...
searchStrings) {
public static boolean endsWith(String str, String suffix) {
public static boolean endsWithIgnoreCase(String str, String suffix) {
public static boolean endsWithAny(String string, String... searchStrings) {

Basic rules being 'if String is returned, then String should be passed
in' and 'if other than String is returned, pass in CharSequence'.

Hen

On Sun, Apr 3, 2011 at 2:45 PM, Henri Yandell  wrote:
> Agreed (apologies for the delay; life got, and is going to remain, very busy).
>
> We should remove the CharSequence code I added. We should also review
> the first batch of CharSequence changes.
>
> I think it's fine to have this:
>
> public int length(CharSequence seq)
>
> I'll look into the removal if no one else gets to it - with a new baby
> in the house that's going to depend very much on how calm she is.
>
> Hen
>
> On Fri, Mar 18, 2011 at 1:21 AM, Stephen Colebourne
>  wrote:
>> On 18 March 2011 03:56, Henri Yandell  wrote:
>>> Something occurred to me today. We're moving from String to
>>> CharSequence in the API, but not thinking of the use case.
>>>
>>> If I call:
>>>
>>>    StringUtils.toLowerCase(stringBuffer);
>>>
>>> I'd argue that the likely style would be to modify the object being
>>> passed in, not to return it (even if we could return a StringBuffer
>>> instead of a new String). More specifically, if the CharSequence is
>>> mutable, then mutate the passed in value, whereas if the CharSequence
>>> is immutable, return a new version.
>>>
>>> This makes me wonder if there's any value in moving to CharSequence.
>>
>> As I've probably said before, I think that most people are looking for
>> a StringUtils operating on Strings and nulls. I personally never hold
>> CharSequence as a variable, although obviously I use StringBuffer,
>> StringBuilder and StrBuilder. But, I rarely have a CharSequence that
>> is null - it doesn't make that much sense to do so as mutable strings
>> are transient.
>>
>> The significant class IMO.is StrBuilder, which is [lang] owned. That
>> is where all these utility methods go, Thus you can do:
>>
>> StrBuilder b = ...
>> b.setLowerCase()
>>
>> If you need to operate on a StringBuffer or StringBuilder? Well,
>> don't! [lang] says use StrBuilder. That was the original design, and
>> frankly i

Re: [ALL] source compatibility - changes to throws clauses

[Henri Yandell]

On Sat, Apr 2, 2011 at 6:44 AM, sebb  wrote:
> On 1 April 2011 02:53, Phil Steitz  wrote:
>> On 3/31/11 6:30 PM, sebb wrote:
>>> Just discovered that Clirr does not complain if the throws clause of a
>>> method or constructor is changed to add a new Exception.
>>> Seemed like a bug at first, but it's not, because throws clauses are
>>> only checked at compile-time.
>>>
>>> So e.g. adding "throws IOException" to a method will not break binary
>>> compatibilty, but of course anyone recompiling against the updated
>>> binary code will get a compiler error (if they don't already handle
>>> the error).
>>>
>>> [This is perhaps why some incompatibilities in Math 2.x were not
>>> discovered by Clirr]
>>>
>>> The Commons versioning rules require that changes to method signatures
>>> necessitate a major release, so changes to throws clauses mean a major
>>> release is required.
>>>
>>> Since this does not affect binary compatibility, AFAICT there is no
>>> technical reason to require a package name change.
>>>
>>> A major release generally means that the user will want to make code
>>> changes anyway to take advantage of new features, so I don't see this
>>> as a big problem.
>>> But we should try do document such changes.
>>>
>>> Clirr is not sufficient to detect whether a major version change is
>>> required, so perhaps we need some other tool to detect such changes.
>>> (Does anyone know of one?)
>> I don't know if we can afford the license, but the best one I have
>> seen is "sebb"
>> he he ;)
>
> Thanks ...
>
>> Sorry, could not resist that.  I don't know of any better freely
>> available tools than Clirr.  Maybe best to raise an issue there.
>
> I could not find anything either, but it turned out not too difficult
> to use BCEL (*) to scan two classpaths/jars and compare the throws
> clauses for methods with identical signatures. The tricky bit is where
> a method has been pulled up to a super-class; I've not entirely solved
> that yet.
>
> But I agree that if Clirr could be extended to also optionally check
> source compatibility that would be better in the long run, as Clirr
> already needs to deal with pull-ups etc. I'll raise an enhancement
> request.
>
> (*) started by trying reflection, however that requires all referenced
> classes to be present on the classpath, including exceptions from 3rd
> party libs.

This might be useful:

https://code.google.com/p/osjava/source/browse/#svn%2Ftrunk%2Fjardiff

I used to use it instead of clirr. It covers added exceptions.

Hen

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

Re: [VOTE] Release Apache Commons Discovery 0.5-RC1

[Henri Yandell]

Warnings :)

On Sun, Apr 3, 2011 at 7:29 PM, Gary Gregory  wrote:
> Any thoughts on fixing the 300+ checkstyle errors?
>
> Gary
>
> On Sun, Apr 3, 2011 at 5:11 PM, Simone Tripodi 
> wrote:
>
>> Hi all guys!
>> we haven't released a new version of Apache Commons Discovery since
>> 2008 (!!!), since I recently had to use it in a project I thought it
>> would have been fine having at least the Java5 generics support.
>> So, after 2 days of hard work - and thanks for feedbacks from dev
>> community - I'm here to propose a new release, please cast your votes!
>> Many thanks in advance to everybody will take part to the vote
>> process, all the best,
>> Simo
>>
>> Release notes:
>>
>> http://people.apache.org/builds/commons/discovery/0.5/RC1/RELEASE-NOTES.txt
>>
>> Tag:
>>
>>
>> http://svn.apache.org/repos/asf/commons/proper/discovery/tags/DISCOVERY_0_5_RC1/
>>
>> Site:
>>
>> http://people.apache.org/builds/commons/discovery/0.5/RC1/site/
>>
>> Binaries:
>>
>>
>> http://people.apache.org/builds/commons/discovery/0.5/RC1/staged/commons-discovery/commons-discovery/0.5/
>>
>> [ ] +1 release it
>> [ ] +0 go ahead I don't care
>> [ ] -1 no, do not release it because
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> --
> Thank you,
> Gary
>
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>

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

Re: [lang] CharSequenceUtils resurrection? [Was: Remaining work]

[Henri Yandell]

On Sun, Apr 3, 2011 at 7:10 PM, Gary Gregory  wrote:
> On Sun, Apr 3, 2011 at 7:47 PM, Henri Yandell  wrote:
>>
>> I've rolled the code back. Now I'm thinking the following are
>> candidates to roll back to String:
>>
>>    public static String stripAccents(CharSequence input) {
>>    public static String capitalize(CharSequence cs) {
>>    public static String uncapitalize(CharSequence cs) {
>>



>>
>> Basic rules being 'if String is returned, then String should be passed
>> in' and 'if other than String is returned, pass in CharSequence'.
>
> Like it. +1

I've rolled back capitalize and uncapitalize. I'm leaving stripAccents
as it sits on top of an underlying API that is CharSequence based -
ie) the JDK has already declared a CharSequence in; String out
behaviour.

Hen

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

Re: [ALL] @authors tags

[Henri Yandell]

On Mon, Apr 4, 2011 at 9:28 PM, Christian Grobmeier  wrote:
> On Mon, Apr 4, 2011 at 11:22 PM, Phil Steitz  wrote:
>> On 4/4/11 2:18 PM, Torsten Curdt wrote:
 I thought we had settled on '@author Apache Software Foundation',
>>> Did we? TBH I find that pretty pointless and nothing more than noise.
>>> I'd be in favor of removing them all together.
>> I agree with Torsten.  I got stalled in DBCP/pool because at least
>> some ppl thought we needed to get permission from all of the long
>> gone @authors to nuke their tags.  Personally, I am ready to just
>> nuke 'em if others do not object.
>
> I am +1 for nuking and +1 for documenting the "no @author tags" decision

+1, and done for Lang.

Hen

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

Re: [codec] Moving on to codec 2.0

[Henri Yandell]

+1 to all of the below.

The lesson from Lang imo is to charge in and just do it. It'll
generate ideas once people are free to consider backwards incompatible
changes. Rolling back is always possible if we decide we didn't really
justify a 2.0.

Look at what else is out there. Is the scope of Codec correct, are
there things that should be added to the scope. Is there other useful
code that can be included.

Hen

On Tue, Mar 29, 2011 at 10:44 AM, Gary Gregory  wrote:
> Hi All,
>
> Now that codec 1.5 is out, I would like thoughts on this plan for codec 2.0:
>
> - Create a SVN branch for 1.x
>
> Then in trunk:
> - Correct Maven group id, which implies:
> - Repackage to o.a.c.codec2
> - Use Java 5
> - Use JUnit 4
>
> What else? Thoughts?
>
> Thank you,
> Gary
> --
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>

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

Re: [ALL] @authors tags

[Henri Yandell]

On Mon, Apr 4, 2011 at 10:31 PM, Henri Yandell  wrote:
> On Mon, Apr 4, 2011 at 9:28 PM, Christian Grobmeier  
> wrote:
>> On Mon, Apr 4, 2011 at 11:22 PM, Phil Steitz  wrote:
>>> On 4/4/11 2:18 PM, Torsten Curdt wrote:
>>>>> I thought we had settled on '@author Apache Software Foundation',
>>>> Did we? TBH I find that pretty pointless and nothing more than noise.
>>>> I'd be in favor of removing them all together.
>>> I agree with Torsten.  I got stalled in DBCP/pool because at least
>>> some ppl thought we needed to get permission from all of the long
>>> gone @authors to nuke their tags.  Personally, I am ready to just
>>> nuke 'em if others do not object.
>>
>> I am +1 for nuking and +1 for documenting the "no @author tags" decision
>
> +1, and done for Lang.

Btw:

for i in `find . -type f -name '*.java'`; do (echo 'g/@author/d'; echo
'w') | ed $i; done

and check with svn diff of course :)

Hen

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

Fixing all warnings? [Was: [VOTE] Release Apache Commons Discovery 0.5-RC1]

[Henri Yandell]

On Mon, Apr 4, 2011 at 5:13 AM, Gary Gregory  wrote:
> On Apr 4, 2011, at 1:45, Simone Tripodi  wrote:
>
>> Hi Gary!
>> I honestly even thought about it, so sorry! :( Since Discovery
>> activity has not been hight since 2008, I just thought adding the
>> missing generics support and nothing more :(
>> I don't think that should be a blocking issue since we've been
>> "overlooked" them for a long time, BTW if we think the effort of
>> fixing the checkstyle warnings can help the component health, I'll
>> cancel this vote and rollout a new one as soon as I can.
>> WDYT? Many thanks in advance for your feedbacks!
>> Have a nice day,
>> Simo
>
> IMO a release should be a clean as possible. I also like the release
> early release often pattern so you could fix it all next. I am not
> sure what your plans are for further releases. If you are working
> towards more releases toward a 1.0 then it's ok I suppose.

I increasingly find that feels wrong. We're in the release
early/release often business and trying to over-polish not only pushes
the release back, but it also decreases the release often as there are
less items to do.

Somewhere in my gut I feel it might be worse than that. There's a
"someone cares" level of quality to achieve, but minor imperfections
can drive community. The bugs in our software are our recruitment
drive, and getting rid of all of the low-hanging-fruit interferes with
that. That seems insane if we put our business developer hats on, but
you have to remember that what we do also seems insane.

My take away on these internal gastric rumblings has been:

* If you are the only committer actively working on a project; and
it's been that way for a while; then leave the warts. Focus on the
important subjects and get releases out.
* If you are newish to driving the project, fix the warnings. It's a
good practice and gets you into the code more.
* If there are lots of committers; fix some of the warnings. Lead by
example but don't do all the work.

We have slowly increasing minutiae roadblocks to releases and I've
moved over the years from "it helps build quality" over to "it gets in
the way of community development".

Hen

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

Re: Fixing all warnings? [Was: [VOTE] Release Apache Commons Discovery 0.5-RC1]

[Henri Yandell]

On Tue, Apr 5, 2011 at 12:40 AM,   wrote:
>
> - "Henri Yandell"  a écrit :
>
>> On Mon, Apr 4, 2011 at 5:13 AM, Gary Gregory 
>> wrote:
>> > On Apr 4, 2011, at 1:45, Simone Tripodi 
>> wrote:
>> >
>> >> Hi Gary!
>> >> I honestly even thought about it, so sorry! :( Since Discovery
>> >> activity has not been hight since 2008, I just thought adding the
>> >> missing generics support and nothing more :(
>> >> I don't think that should be a blocking issue since we've been
>> >> "overlooked" them for a long time, BTW if we think the effort of
>> >> fixing the checkstyle warnings can help the component health, I'll
>> >> cancel this vote and rollout a new one as soon as I can.
>> >> WDYT? Many thanks in advance for your feedbacks!
>> >> Have a nice day,
>> >> Simo
>> >
>> > IMO a release should be a clean as possible. I also like the
>> release
>> > early release often pattern so you could fix it all next. I am not
>> > sure what your plans are for further releases. If you are working
>> > towards more releases toward a 1.0 then it's ok I suppose.
>>
>> I increasingly find that feels wrong. We're in the release
>> early/release often business and trying to over-polish not only
>> pushes
>> the release back, but it also decreases the release often as there
>> are
>> less items to do.
>>
>> Somewhere in my gut I feel it might be worse than that. There's a
>> "someone cares" level of quality to achieve, but minor imperfections
>> can drive community. The bugs in our software are our recruitment
>> drive, and getting rid of all of the low-hanging-fruit interferes
>> with
>> that. That seems insane if we put our business developer hats on, but
>> you have to remember that what we do also seems insane.
>
> I would never have thought about bugs as an incentive for newcomers.
>
> It does make sense.
>
>>
>> My take away on these internal gastric rumblings has been:
>>
>> * If you are the only committer actively working on a project; and
>> it's been that way for a while; then leave the warts. Focus on the
>> important subjects and get releases out.
>> * If you are newish to driving the project, fix the warnings. It's a
>> good practice and gets you into the code more.
>> * If there are lots of committers; fix some of the warnings. Lead by
>> example but don't do all the work.
>
> I think there is also another criterion:
>
>  * if there is an overwhelming number of warnings, reduce it drastically
>   to a manageable number
>
> There are two reasons for this criterion. The first reason is that when you 
> have
> hundreds or thousands of javac/javadoc/eclipse/checkstyle/findbugs/clirr/Sebb
> warnings, it is easy to miss an important one hidden by numerous minor ones.
> The second reason is that when there are two many warnings, this may also 
> drive
> wannabe committers away, either because they feel the current team is not
> interested in quality fixes or because they are afraid by the amount of work 
> to
> fix things.

Agreed. It's not that fixing warnings are bad, it's that making them
release blockers is an anti-pattern.

The most painful thing btw is doing a new major version of a component
- you get stuck in a "can't release" cycle. We need to solve that one,
Lang 3.0 should have been pushing out monthly alphas (on apache.org
and in Maven).

Gary - that's my major advice for Commons Codec 2.0. Plan on an alpha
release every month. Even pick the recurring day. Shove it through and
keep it fast. Get the alphas on the Maven repos. Don't allow things to
block the monthly release beyond Legal and badly fubar.

Hen

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

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[Henri Yandell]

Very late, but I've been a tad busy in the new-parent department.

Generally I agree with Phil's email. I don't really care though - I
recognize that my main pain with Nexus is a) the experience to know
not to trust magical systems & b) not being full of energy to follow
yet another build system change. I'm sure Maven 3.0 will be coming and
I'll have to find the time to look into that.

I've a bunch of JIRA plugins that are basically dead now because
Atlassian moved to OpenSocial and I don't have the time/interest to
read up on OpenSocial. This is the same - major shifts are costly and
I'm now in the 'can't keep up'. My time is worth more to me than the
novelty of the features :) Sucks to be me.

What I do care about is releasing often. Which is farcical given how
few times I've released. I want to release every month. Every week if
possible. With minimal effort as I don't have the time to waste
building releases for code that is fine enough. If that means pressing
some magic button and Nexus takes care of things; fine. I'm loathe to
read the 7 pages of "How to Release updated for Nexus", but I
recognize that a lot of that is my own lacking. That said 97% of it is
boring as it's really How to Release [the Nexus version] and not the
10 line page that its title implies it should be).

[Side note; this is insane:
http://maven.apache.org/guides/mini/guide-encryption.html - I vomit
every time it's implied I should put passwords in the Maven settings
file]

End of opinion :)

Hen

On Tue, Mar 29, 2011 at 7:50 AM, Phil Steitz  wrote:
>  After another nightmare by an RM who has not cut a release in a
> while, I think we need to do something.  The documentation on the
> Commons web pages describes a process that works.  I suggest that we
> standardize on that process, adding some simple automation scripts
> that RMs can choose to use or not to use for the manual steps and
> stop fussing with Nexus or the maven release plugin.  I cut an RC
> last night in 25 minutes (about 15 of which were spent waiting for
> the [pool] tests to complete) and will likely spend about that same
> amount of time deploying the artifacts to dist/ and what remains of
> our simple, file-and-directory-based replication infrastructure to
> get maven artifacts pushed to the maven repos.  I do use a simple
> shell script to manage invoking the maven commands and copying files
> around to reduce the required time from, say an hour, to 25
> minutes.  The script is in svn.
>
> I prefer the "manual" approach for the following reasons:
>
> 1.  I know what it does.  Exactly, every time.  I know that exactly
> the binaries that we vote on get deployed to dist/ and exactly the
> committed tag is used to build everything.  The process includes
> local generation of artifacts that I can inspect and test locally
> and verify sigs.  I know at each step exactly what is being pushed
> where.
>
> 2.  I know that it works.  Every time.  No pom-tweaking,
> plugin-munging or other half-success management required.
>
> 3.  It has no commercial / proprietary dependencies.  The scripts
> are optional and are in any case, ASF-licensed, committed to svn.
>
> I know others have different opinions on this.  It could be we need
> to support both ways of cutting releases.  I would ask, however,
> that those arguing for the "automagical" approach take a hard look
> at how many volunteer hours are being spent trying to get
> maven/nexus to be a release manager and how comparatively little
> time those of us who take the "manual" approach spend getting our
> releases built and deployed.  While I certainly can't claim to
> produce perfect artifacts (much less code :), I will also point out
> that the only major release quality problem that we have had
> recently was the inadvertent release of a [net] version while
> fiddling with the release plugin.  I don't at all buy the argument
> that the manual approach is "error-prone" as it allows more and
> better opportunities for inspection by the RM and community at each
> stage.
>
> 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

Re: Passwords in Maven settings file [Was: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1]

[Henri Yandell]

On Tue, Apr 5, 2011 at 2:37 AM, sebb  wrote:
> On 5 April 2011 09:32, Jochen Wiedmann  wrote:
>> On Tue, Apr 5, 2011 at 10:22 AM, Henri Yandell  wrote:
>>
>>> [Side note; this is insane:
>>> http://maven.apache.org/guides/mini/guide-encryption.html - I vomit
>>> every time it's implied I should put passwords in the Maven settings
>>> file]
>>
>> Totally agreed!
>
> There are a couple of ways around that.
>
> 1) Use settings-security.xml  to store the real
> settings-security.xml on a removable device.

Vomiting more :) At least I know when I physically lose my laptop.

The docs also need to be pushing "encrypted removable device" more.
It's taken as read that people will do that.

> 2) It would be nice if Maven supported a keyserver of some kind (cf.
> Pageant for Putty), but it does not. However one can use the
>  element to point to a server that returns the passwords.
> I wrote a Java app that acts as a simple keyserver; of course that
> needs its own password.
>
> If the device is not present, or the server is not running, you get a
> warning message when starting Maven builds.
> [When using the keyserver I normally give it a dummy password, as that
> avoids the time delay when Maven looks for the server; however one
> still gets warnings]

Entering at the command line is fine for me. :)

Hen

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

Re: [ALL] @authors tags

[Henri Yandell]

If anyone wants their @author tag put back into Lang, then please feel
free to do so; or if you don't have commit access send me an email and
I'll gladly do it.

Hen

On Tue, Apr 5, 2011 at 12:40 PM, Emmanuel Bourg  wrote:
> I guess I'll never understand the hate for this tag. If you don't like it,
> don't use it. But please don't remove the name of other developers without
> their consent.
>
> Emmanuel Bourg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

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

Re: [ALL] @version tag :)

[Henri Yandell]

On Tue, Apr 5, 2011 at 12:53 PM, Emmanuel Bourg  wrote:
> Le 05/04/2011 11:59, Simone Tripodi a écrit :
>>
>> Hi all guys!
>> I think we all should agree on adopting a common policy, it shouldn't
>> be dependent by who takes care of a component.
>> I see different opinion about @version tag usage, so what's next?
>> shall we calla  vote to make a definitive decision?
>> I'm worried that this discussion could degenerate in a lng thread :P
>> Simo
>
> Well with this and the @author tags you've hit a nerve. Please wait a bit
> before starting the next discussion about brace placement, indentation size
> or Git migration ;)

I want to see what's next! I can't wait a bit, that's FOREVER!

Hen

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

Re:

[Henri Yandell]

Sorry - this is/was me being opinionated that Checkstyle doesn't
report errors, it reports warnings.

Hen

On Mon, Apr 4, 2011 at 4:57 AM, Gary Gregory  wrote:
> Gary
>> Warnings :)
>
> Hm. The top of the report says 0 warnings and 329 errors.
> Gary
>
>>
>> On Sun, Apr 3, 2011 at 7:29 PM, Gary Gregory  wrote:
>>> Any thoughts on fixing the 300+ checkstyle errors?
>>>
>>> Gary
>>>
>>> On Sun, Apr 3, 2011 at 5:11 PM, Simone Tripodi 
>>> wrote:
>>>
 Hi all guys!
 we haven't released a new version of Apache Commons Discovery since
 2008 (!!!), since I recently had to use it in a project I thought it
 would have been fine having at least the Java5 generics support.
 So, after 2 days of hard work - and thanks for feedbacks from dev
 community - I'm here to propose a new release, please cast your votes!
 Many thanks in advance to everybody will take part to the vote
 process, all the best,
 Simo

 Release notes:

 http://people.apache.org/builds/commons/discovery/0.5/RC1/RELEASE-NOTES.txt

 Tag:


 http://svn.apache.org/repos/asf/commons/proper/discovery/tags/DISCOVERY_0_5_RC1/

 Site:

 http://people.apache.org/builds/commons/discovery/0.5/RC1/site/

 Binaries:


 http://people.apache.org/builds/commons/discovery/0.5/RC1/staged/commons-discovery/commons-discovery/0.5/

 [ ] +1 release it
 [ ] +0 go ahead I don't care
 [ ] -1 no, do not release it because

 http://people.apache.org/~simonetripodi/
 http://www.99soft.org/

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


>>>
>>>
>>> --
>>> Thank you,
>>> Gary
>>>
>>> http://garygregory.wordpress.com/
>>> http://garygregory.com/
>>> http://people.apache.org/~ggregory/
>>> http://twitter.com/GaryGregory
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

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

[lang] StringUtils CharSequenced

[Henri Yandell]

StringUtils is ready now I believe.

The 7 methods on the end have now been moved to the resurrected
CharSequenceUtils class. It only has 1 public class, but I think the
other methods can be added over time. Not something to block 3.0 on,
but they seem useful [in that they've been useful for StringUtils
already].

Hen

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

[lang] alpha package

[Henri Yandell]

I've been pondering the tension between stability and innovation.

Once 3.0 is out I'd like to add an alpha subpackage:

  org.apache.commons.lang-alpha

It's specifically a location of code that is:

  a) Not linked to a version. When we move to 4.0 it does not change.
  b) Does not offer backwards compatibility. Classes move out of
lang-alpha and into lang3 (or lang4 etc).

Not all new code goes there, but much does. The 'contrib' package of
an open source project is an essential aspect of allowing the project
to innovate without burden. If I can convince us to achieve a goal of
frequent releases, we'll need to be able to release code that we're
not 100% sure about into our stable packages. It doesn't solve the
cataclysmic changes (moving to Java 5.0 for example), but it handles a
lot of items.

I'm not wedded to the alpha name btw; would love to hear of a better one.

A side effect that I like is that people can monitor the changes to
the alpha package to get a feel for what's coming/what's arrived.

Hen

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

[lang] Collections -> Lang

[Henri Yandell]

Deja Vu time.

Collections is dead. I hereby give notice that there are a few basic
classes in Collections that I want to copy into Lang and genericize
(ComparableComparator, ReverseComparator etc - dull stuff instead of
serious data structures).

Vision-wise I'm seeing that as Lang 3.1 (i.e. JIRA's 3.1 is noise; in
fact I'll rename that to 3.x :) ).

Hen

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