Re: [VALIDATOR] Ready for 1.4.1 RC3?

[Paul Benedict]

If you are bumping the minimum java version, this should be really 1.5.
Technically the bump won't be a true drop in for someone on 1.4 but who
is on 1.4 anymore? Your call.
On Jan 5, 2015 10:11 AM, "Benedikt Ritter"  wrote:

>
>
> Send from my mobile device
>
> > Am 05.01.2015 um 16:34 schrieb sebb :
> >
> >> On 5 January 2015 at 14:33, Benedikt Ritter  wrote:
> >> 2015-01-05 15:09 GMT+01:00 sebb :
> >>
>  On 5 January 2015 at 07:03, Benedikt Ritter 
> wrote:
>  Hi all,
> 
>  there have been some fixes in the last few days (mostly thanks to
> sebb)
> >>> and
>  my feeling is, that we're ready to cut 1.4.1 RC3.
> >>>
> >>> Yes, I think it is in a stable state.
> >>> I have been checking the source with Java 1.4 on a Windows VM and it
> >>> passes.
> >>>
>  If there is something left you would like to add, then please let me
> >>> know.
> >>>
> >>> I'm still wondering about VALIDATOR-235 - allowing IDN names.
> >>>
> >>> I've just updated the issue with two possible approaches.
> >>>
> >>> Assuming we want to do it at all, I favour the reflection approach, as
> >>> it is likely the one we would take if the code needed 1.6.
> >>> When the minimum of Java 1.6 is reached, the reflection code can
> >>> simply be removed.
> >>> If the code checks for non-ASCII content first, the reflection code
> >>> won't be used unnecessarily.
> >>>
> >>
> >> Why not update to Java 1.6 after 1.4.1? Do you rather want to target
> Java
> >> 1.5?
> >
> > No, 1.6 would be fine. We need the IDN class.
> >
> >> Really, I wouldn't put the effort in something that will be removed
> after
> >> this release (meaning the reflection thingy)...
> >
> > I've already done most of the code as part of DomainValidatorTest.
> > It just needs to be repackaged slightly.
> > Also need a unit test, but that will be needed later anyway.
> >
> > Implementing this would allow the current release to work under 1.6+
> > for Unicode domains right now - no need for users to wait for the next
> > release.
> > So IMO I think it's worth a bit of extra work now.
>
> Okay understood. Then go for it!
>
> Benedikt
>
> >
> >>
> >>>
> >>> I'll look into this shortly, but wait for confirmation before
> committing.
> >>>
>  Otherwise I'll cut RC3 tonight or tomorrow.
> >>>
> >>> Thanks!
> >>>
>  Regards,
>  Benedikt
> 
>  --
>  http://people.apache.org/~britter/
>  http://www.systemoutprintln.de/
>  http://twitter.com/BenediktRitter
>  http://github.com/britter
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>
> >>>
> >>
> >>
> >> --
> >> http://people.apache.org/~britter/
> >> http://www.systemoutprintln.de/
> >> http://twitter.com/BenediktRitter
> >> http://github.com/britter
> >
> > -
> > 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] Use of "Review Patch"

[Paul Benedict]

Odd way to use versions, imo. Sounds like "discussion" and "review patch"
and "patch needed" tags would be the better tool.


Cheers,
Paul

On Wed, Apr 15, 2015 at 3:18 PM, Duncan Jones  wrote:

> Hi folks,
>
> Currently the "Review Patch" fix version seems to be applied whenever
> code has been supplied in an issue. This includes situations where
> agreement hasn't yet been reached on fixing the issue and where the
> supplied "patch" is minimal at best.
>
> I would prefer if we only use this marker on issues where the
> discussions have already been completed and we've decided we want to
> go ahead with the alteration/addition.
>
> Do others agree with this? If so, I'll edit existing issues to match
> this. I then plan to try and clean up some of the "Discussion" items,
> so that we either close them or move them to "Review Patch" or "Patch
> Needed".
>
> Duncan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [dbcp] 2.0 prep

[Paul Benedict]

If you are changing the groupId, there's no point in changing the artifactId.

On Sat, Oct 16, 2010 at 9:38 PM, Phil Steitz  wrote:
> I just created a dbcp 1.4 legacy branch, so we can now start work toward
> dbcp 2.0 in trunk.  Pool is already off to the races.  As we have discussed,
> I would like to start exploring bringing in the Tomcat jdbc-pool code, split
> somehow between [pool] and [dbcp].
>
> To get [dbcp] moving, I would like to make the following pom changes in
> trunk:
>
> 0) change the groupId to org.apache.commons
> 1) change the artifactId to commons-dbcp2
> 2) change the pool dependency version to 2.0-SNAPSHOT
>
> Both 1) and 2) may be controversial, so I want to allow people to weigh in
> before making these changes.  I know we like to avoid snapshot dependencies,
> but I don't see any other way to keep the API changes in synch.  Any better
> ideas?
>
> Thanks!
>
> 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: [dbcp] 2.0 prep

[Paul Benedict]

Oh I've been reading :-) I participated in the Lang 3 decision and we
decided (1) new package name (2) new groupId (3) same artifactId.

Why do you think you need to change the artifactId? Look below and
tell me what you don't like about this progression.

commons-dbcp:commons-dbcp:1.4
org.apache.commons:commons-dbcp:2.0
org.apache.commons:commons-dbcp:3.0


Paul

On Sat, Oct 16, 2010 at 11:29 PM, Phil Steitz  wrote:
> On 10/16/10 11:02 PM, Paul Benedict wrote:
>>
>> If you are changing the groupId, there's no point in changing the
>> artifactId.
>
> See related discussion on [pool].  While we can avoid changing the
> artifactId for 2.0 since the groupId change creates the necessary separation
> of artifacts, we will need to do it subsequently.  I agree with James and
> others that it is best to maintain the simple convention that at least for
> low-level components, we tie the artifactId to the major release series.
>
> Phil
>
>>
>> On Sat, Oct 16, 2010 at 9:38 PM, Phil Steitz
>>  wrote:
>>>
>>> I just created a dbcp 1.4 legacy branch, so we can now start work toward
>>> dbcp 2.0 in trunk.  Pool is already off to the races.  As we have
>>> discussed,
>>> I would like to start exploring bringing in the Tomcat jdbc-pool code,
>>> split
>>> somehow between [pool] and [dbcp].
>>>
>>> To get [dbcp] moving, I would like to make the following pom changes in
>>> trunk:
>>>
>>> 0) change the groupId to org.apache.commons
>>> 1) change the artifactId to commons-dbcp2
>>> 2) change the pool dependency version to 2.0-SNAPSHOT
>>>
>>> Both 1) and 2) may be controversial, so I want to allow people to weigh
>>> in
>>> before making these changes.  I know we like to avoid snapshot
>>> dependencies,
>>> but I don't see any other way to keep the API changes in synch.  Any
>>> better
>>> ideas?
>>>
>>> Thanks!
>>>
>>> Phil
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

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

Re: [dbcp] 2.0 prep

[Paul Benedict]

It makes perfect sense if you want multiple versions of DBCP on the
classpath. We had that discussion with Lang 3 as well.

Paul

On Sun, Oct 17, 2010 at 10:52 AM, Simone Tripodi
 wrote:
> Hi Phil,
> I'm sure the build will be broken at least at the beginning, this
> morning I migrated the commons-pool pom metadata and package.
> Please let me know if I can be helpful on dbcp too, thanks in advance.
> Have a nice day,
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Sun, Oct 17, 2010 at 5:35 PM, Phil Steitz  wrote:
>> On 10/17/10 9:57 AM, Jörg Schaible wrote:
>>>
>>> Hi Phil,
>>>
>>> Phil Steitz wrote:
>>>
 I just created a dbcp 1.4 legacy branch, so we can now start work
 toward dbcp 2.0 in trunk.  Pool is already off to the races.  As we
 have discussed, I would like to start exploring bringing in the
 Tomcat jdbc-pool code, split somehow between [pool] and [dbcp].

 To get [dbcp] moving, I would like to make the following pom changes
 in trunk:

 0) change the groupId to org.apache.commons
 1) change the artifactId to commons-dbcp2
 2) change the pool dependency version to 2.0-SNAPSHOT

 Both 1) and 2) may be controversial, so I want to allow people to
 weigh in before making these changes.  I know we like to avoid
 snapshot dependencies, but I don't see any other way to keep the API
 changes in synch.  Any better ideas?
>>>
>>> All arguments have already been spoken. So, +1 to al of this.
>>
>> Thanks.  I am wondering what CI stuff may break if we move to snapshot
>> dependency.  Any comments on that?
>>
>> Phil
>>>
>>> - Jörg
>>>
>>>
>>> -
>>> 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: [pool][dbcp] cross pollination

[Paul Benedict]

Has any thought been given to simply rolling the projects into one?

On Sun, Oct 17, 2010 at 2:13 PM, Phil Steitz  wrote:
> On 10/17/10 2:58 PM, Gary Gregory wrote:
>>
>> Shouldnt we talk more across these two projects? Perhaps making sure we
>> have good reuse and cross pollination
>
> Commons is *one* project.  That said, the answer is obviously yes. As we
> start to bring in the jdbc-pool stuff, this will become even more apparent.
>  Coordination between [pool] and [dbcp] has never been an issue in the past
> and I don't see that changing now.  Often fixing issues in [dbcp] ends up
> leading to [pool], so there has always been a lot of overlap in contributors
> to these two.
>
> Phil
>>
>> Gary
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

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

Re: [pool][dbcp] cross pollination

[Paul Benedict]

I didn't mean to imply one artifact with my suggestion. I would
continue publishing two artifacts no matter what.

On Mon, Oct 18, 2010 at 9:44 AM, Simone Tripodi
 wrote:
> Hi all,
> even if as developer was involved I recently, in therms of APIs, as
> user, I'd prefeer keeping the 2 things separated:
>
>  * the pool is a set of APIs with interfaces and some concrete
> implementations to create generic pools; i.e. I used it to pool
> instances of commons-digester parsers or httpclient instances;
>
>  * the DBCP is a specific DatSource pool.
>
> I wouldn't like adding a generic pool library that brings the JDBC
> connection pooling stuff, IMHO it continues making sense keeping the 2
> separated.
> Just my 2 cents,
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Mon, Oct 18, 2010 at 3:38 PM, Paul Benedict  wrote:
>> Has any thought been given to simply rolling the projects into one?
>>
>> On Sun, Oct 17, 2010 at 2:13 PM, Phil Steitz  wrote:
>>> On 10/17/10 2:58 PM, Gary Gregory wrote:
>>>>
>>>> Shouldnt we talk more across these two projects? Perhaps making sure we
>>>> have good reuse and cross pollination
>>>
>>> Commons is *one* project.  That said, the answer is obviously yes. As we
>>> start to bring in the jdbc-pool stuff, this will become even more apparent.
>>>  Coordination between [pool] and [dbcp] has never been an issue in the past
>>> and I don't see that changing now.  Often fixing issues in [dbcp] ends up
>>> leading to [pool], so there has always been a lot of overlap in contributors
>>> to these two.
>>>
>>> Phil
>>>>
>>>> Gary
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>
>> -
>> 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: [ANNOUNCE] Commons IO 2.0 released

[Paul Benedict]

Niall, congratulations on your hard work and persistence with this
release. Nice job.

Paul

On Sat, Oct 23, 2010 at 8:12 AM, Niall Pemberton  wrote:
> The Apache Commons team is pleased to announce the release of Commons IO 2.0.
>
> Commons IO 2.0 requires a minimum of JDK 1.5, but is otherwise
> backwards compatible with the previous 1.4 release (which required a
> minimum of JDK 1.3).
>
> This release contains a number of enhancements and bug fixes - full
> details of which can be found in the release notes:
>    http://commons.apache.org/io/upgradeto2_0.html
>
> For information on Commons IO please visit the IO website:
>    http://commons.apache.org/io/
>
> Commons IO can be downloaded from the following page:
>    http://commons.apache.org/io/download_io.cgi
>
>
> Niall
> on behalf of the Apache Commons community
>
> -
> 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: [VFS] Softening the exceptions...

[Paul Benedict]

+1 for softening all exceptions. The fact is, what reasonable recourse
is there to the user if a file operation fails? That's what checked
exceptions were supposed to be for -- mandate handling code. It's
tough to say we need to mandate handling these errors.

Paul

On Mon, Oct 25, 2010 at 10:49 AM, Ralph Goers
 wrote:
>
> On Oct 25, 2010, at 8:10 AM, James Carman wrote:
>
>> On Mon, Oct 25, 2010 at 11:05 AM, Gary Gregory
>>  wrote:
>>> Do we want the APIs to be quieter than using java.io.File for example? Or, 
>>> should exceptions be thrown from similar places?
>>>
>>
>> Definitely quieter than java.io.File!  I *hate* that API for its
>> checked exceptions.
>>
>>> I am worried that we would make all APIs "quiet" (unchecked exceptions) as 
>>> a opposed to really thinking where exceptions should be checked or return 
>>> an Boolean error code (like File mkdir)
>>>
>>
>> I'm one of those folks who think the checked exceptions are evil, so I
>> am fine with getting rid of them entirely (think about how much nicer
>> your Hibernate code looks without the checked exceptions).  Boolean
>> returns are fine I guess.  No real strong opinion on that one.
>>
>
> I'm not in favor of changing much at this point. I'd really like to get a 
> release done without too many more changes.
>
> Ralph
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

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

Re: [VFS] Softening the exceptions...

[Paul Benedict]

Checked exceptions throw a burden onto the developer. He is forced to
do something. Why force this burden? It assumes something SHOULD be
done for these particular errors. I don't think that's realistic
(they're OS errors -- not business errors), which is why checked
exceptions have fallen well out of favor in the last decade.

On Mon, Oct 25, 2010 at 12:48 PM, Filip Defoort
 wrote:
> On Mon, Oct 25, 2010 at 10:45 AM, James Carman
>  wrote:
>> On Mon, Oct 25, 2010 at 1:41 PM, Filip Defoort
>>  wrote:
>>>
>>> Yes! Very much so. It's quite useful when dealing with stale nfs,
>>> locked files,...
>>>
>>
>> Do you implement the retry logic in every place where you need it or
>> do you have a helper method that takes some sort of functor and it
>> wraps it in the try/catch/retry logic?
>>
>
> Depends. I do have a bunch of wrappers for common types of retries,
> but often the remedy really is different depending on the operation
> (I'm dealing a lot with search indexes, updating them and transaction
> locking).
>
> - Filip
>
> -
> 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: Pointers

[Paul Benedict]

I believe you're looking for JDK 7 method handles:
http://java.sun.com/developer/technicalArticles/DynTypeLang/

Paul

On Mon, Jan 3, 2011 at 11:45 AM, Michael Giannakopoulos <
miccagi...@gmail.com> wrote:

> Hello to all Apache Commons Developers!
> I wish a happy new year and i hope that all your expectations will come
> true! I would like to propose a new feature in apache commons... Wouldn't
> it
> be great if commons api provided a pointer operator (like ref in C#) so as
> to pass arguments in functions by references (only for primitive types...)
> and these arguments to change values... I would like to hear your thoughts
> on this! Thanks for your time!
>

Re: Pointers

[Paul Benedict]

Michael,

Primitives are passed by value in Java. If you want to "modify" primitives,
use the MutableXXX wrappers in Commons Lang.

Paul

On Mon, Jan 3, 2011 at 3:01 PM, Michael Giannakopoulos  wrote:

> I mean exactly the same thing as C# but from the replies i see that's a
> difficult task and also that has little to do with apache commons...
> Because
> i use java a lot it's annoying the fact that specific variables that i want
> to change values in other functions cannot be passed as arguments but
> instead you have to declare them as arrays or other objects... Thanks for
> all the replies. Do you believe that something like that can start in
> commons?
>

Re: [lang] enum for Java Version [was svn commit: r1065174 - ...]

[Paul Benedict]

I don't understand. Is the enum changing values or is it just getting new
values? The latter is perfectly acceptable. The JDK adds new enum values
where required too, but it won't reorder them or delete existing ones.

On Sun, Jan 30, 2011 at 3:29 PM, 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/licenses/LICENSE-2.0
> > + *
> > + * Unless required by applicable law or agreed to in writing, software
> > + * distributed under the License is distributed on an "AS IS" BASIS,
> > + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> implied.
> > + * See the License for the specific language governing permissions and
> > + * limitations under the License.
> > + */
> > +package org.apache.commons.lang3;
> > +
> > +/**
> >

Re: [lang] enum for Java Version [was svn commit: r1065174 - ...]

[Paul Benedict]

I like this the best:
http://api.dpml.net/openjdk/module/20070627/java/module/Version.html

On Sun, Jan 30, 2011 at 5:43 PM, Henri Yandell  wrote:

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

Re: [math] the 2.2 release saga conclusion ?

[Paul Benedict]

I believe re-organizing the exception hierarchy is a great feature for a
major release. For minor releases, avoid refactoring that would break
current code.

Paul

On Fri, Feb 11, 2011 at 1:23 PM, Phil Steitz  wrote:

> So from the user perspective, the compatibility issue is that code
> that catches MathException will in some cases propagate runtime
> exceptions instead.   This sounds ridiculous, but what would be the
> implications of just reverting the hierarchy so catching
> MathException would work as before, but make MathException itself
> unchecked?
>
> Sorry if this seems to be walking into the kind of discussion you
> did not want to reopen at this point; but I am just trying to see
> what we might be able to do to prevent users having to make code
> changes to have their apps that use 2.1 work safely in 2.2.
>
> I will add at this point that if we just s/2.2/3.0 and s/3.0/4.0, I
> am fine releasing as is.
>
> Phil
>

Re: OGNL as a part of Commons

[Paul Benedict]

Struts 2 is a big consumer of OGNL. The Struts community already consumed
XWork's IP and now own it. Aren't both of those projects from OpenSymphony?
If so, I would say it should go over to Struts.

On Tue, Mar 1, 2011 at 12:50 PM, Stephen Colebourne wrote:

> Based on what I know of OGNL, it is/was reasonably well used. Trying
> to merge it into another project doesn't help those existing users.
>
> The question is what are the author(s) of OGNL looking for? A home for
> maintainance? The Apache brand? To reinvigorate it? The latter fits
> with a merger into other projects. The former should make commons ask
> if it wants to become a home for maintainance mode (not necessarily a
> bad thing).
>
> I'm certainly arguing against a straight push into BeanUtils or JEXL.
>
> Stephen
>
>
> On 1 March 2011 17:48, Simone Tripodi  wrote:
> > Hi Henri,
> > it would be fine for me, I initially suggested BeanUtils because
> > already support a similar feature[1], but JEXL2 would work as well.
> > Thanks for your feedbacks, looking forward to collect enough thoughts
> > to call for a vote :)
> > Simo
> >
> > http://people.apache.org/~simonetripodi/
> > http://www.99soft.org/
> >
> >
> >
> > On Tue, Mar 1, 2011 at 6:37 PM, henrib  wrote:
> >> Howdy;
> >> I looked at OGNL a while ago and can't fully remember why I ended up
> using
> >> JEXL (probably because it seemed simpler). Anyway, OGNL seems very
> powerful
> >> and expressive.
> >> What about trying to merge OGNL & JEXL2 (instead of BeanUtils)? I'm
> pretty
> >> sure the core JEXL2 features (introspector - method /static / ctor
> calls,
> >> arithmetic) could be leveraged easily. The main differences would be in
> the
> >> upper parts I guess (syntax, constructs).
> >> It probably could help define a better scripting engine and language in
> the
> >> future rather than overlapping ones.
> >> Thoughts ?
> >> Henrib
> >>
> >> --
> >> View this message in context:
> http://apache-commons.680414.n4.nabble.com/OGNL-as-a-part-of-Commons-tp3085026p3330241.html
> >> Sent from the Commons - Dev mailing list archive at Nabble.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
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Math - 403] Never propagate a "NullPointerException" resulting from bad usage of the API

[Paul Benedict]

Giannakopoulos,

It's a debate that goes on. Josh Bloch in his Effective Java book says NPE
is perfectly acceptable for bad arguments. So it really depends on your
perspective what an NPE represents. I prefer Josh's opinion but only because
every single argument probably creates lots of branch-checking that kills
cpu pipelining.

Paul

On Tue, Mar 1, 2011 at 2:01 PM, Michael Giannakopoulos  wrote:

> Hello guys,
>
> As far as this issue is concerned (for what i have understood) i believe
> that one way to separate NULL(s) that occur from the A.P.I. from NULL(s)
> coming from wrong usage of A.P.I. by a user is the assert technique... I
> didn't know a lot about it but from what i have read it should be
> implemented only in the private methods of the A.P.I. Check this link out:
> "
> http://download.oracle.com/javase/1.4.2/docs/guide/lang/assert.html";.
> Another choice is to create a new class that would check all the arguments
> of every function we are interested in (for example: public
> checkArguments(Object... args)) [If i have understood correctly the purpose
> of this issue...]. Any suggestions would be more than welcomed!
>
> Best regards,
> Giannakopoulos Michael
>

Re: [Math - 403] Never propagate a "NullPointerException" resulting from bad usage of the API

[Paul Benedict]

BTW, you can find precedence in the JVM for many methods that throw NPE on
null arguments. I am not saying this is the "right way", since such things
are subjective and are a matter of design, but many people have concluded
it's better.

On Tue, Mar 1, 2011 at 9:16 PM, Bill Barker  wrote:

>
>
> -Original Message- From: Gilles Sadowski
> Sent: Tuesday, March 01, 2011 3:12 PM
> To: dev@commons.apache.org
> Subject: Re: [Math - 403] Never propagate a "NullPointerException"
> resulting from bad usage of the API
>
>
>  Hi.
>>
>>  It's a debate that goes on. Josh Bloch in his Effective Java book says
>>> NPE
>>> is perfectly acceptable for bad arguments. So it really depends on your
>>> perspective what an NPE represents. I prefer Josh's opinion but only
>>> because
>>> every single argument probably creates lots of branch-checking that kills
>>> cpu pipelining.
>>>
>>> > As far as this issue is concerned (for what i have understood) i >
>>> believe
>>> > that one way to separate NULL(s) that occur from the A.P.I. from >
>>> NULL(s)
>>> > coming from wrong usage of A.P.I. by a user is the assert technique...
>>> > I
>>> > didn't know a lot about it but from what i have read it should be
>>> > implemented only in the private methods of the A.P.I. Check this link >
>>> out:
>>> > "
>>> > http://download.oracle.com/javase/1.4.2/docs/guide/lang/assert.html";.
>>> > Another choice is to create a new class that would check all the >
>>> arguments
>>> > of every function we are interested in (for example: public
>>> > checkArguments(Object... args)) [If i have understood correctly the >
>>> purpose
>>> > of this issue...]. Any suggestions would be more than welcomed!
>>>
>>
>> NPE is the symptom of a bug.
>> Using "NullArgumentException" instead of the standard NPE so that the CM
>> exception hierarchy is singly rooted (the root being "MathRuntimeEception"
>> in the development version). An advantage is that it is easy to determine
>> whether an exception is generated by CM. A drawback is that it is
>> non-standard but this is mitigated by the fact that all other exceptions
>> are
>> also non-standard (e.g. "MathIllegalArgumentException" instead of IAE).
>> One has to take into account that we settled on this choice because it
>> makes
>> it somewhat easier to implement other requirements (namely the
>> localization
>> of the error messages). It's a compromise (without the localization
>> requirement, I would have favoured the standard exceptions). And, apart
>> from
>> avoiding code duplication, this choice has some "features" (which might be
>> construed as advantages or drawbacks, depending on the viewpoint)...
>>
>> I'm not sure of what you mean by "branch-checking", but I don't think that
>> checking for null makes the problem bigger than it would be otherwise,
>> since
>> CM already checks for many things.
>>
>> In the end, I'm really not sure what is the best approach for this
>> particular case. Personally, I'd be happy that the CM code never checks
>> for
>> null and let the JVM throw NPE. This would hugely simplify the CM code,
>> albeit at the cost of detecting bad usage a little later. IMHO, it is not
>> a
>> big deal because the bug is that an object is missing somewhere up the
>> call
>> stack, and it should be corrected there...
>>
>>
> I'm in favor of just letting the JVM throw NPE.  Since there is no message
> in this case, there is nothing to localize.  Using a class to check
> arguments is too much work, since the (localized) message "Something was
> null" is less than helpful.  And assert will be turned off in any reasonably
> configured production server so makes the code less readable and adds very
> little value.  If the null happens because of code in CM (as opposed to user
> error), then we'll get a Jira issue, fix it, and add a unit test.  If it is
> user error, then the stack trace of the NPE will tell the developer what was
> wrong in at least 95% of the cases.
>
>
>
>
>  Of course, this would mean that MATH-403 should be dropped, the
>> "NullArgumentException" class removed, and the policy changed to: "Never
>> check for null references".
>>
>>
>> Best,
>> Gilles
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Math - 403] Never propagate a "NullPointerException" resulting from bad usage of the API

[Paul Benedict]

I neglected to mention that Commons Math *should* document what exceptions
are to be expected. If a method is designed to throw NPE because of a null
argument (whether through explicit checking or not), @throws should mention
that.

Paul

On Wed, Mar 2, 2011 at 10:36 AM, Adrian Crum <
adrian.c...@sandglass-software.com> wrote:

> I agree with this view. It would help the developer who uses CM if the
> library told him/her what they did wrong ("argument 'foo' cannot be null")
> instead of a simple exception thrown message ("NullPointerException thrown
> at line nnn of class Xyz").
>
> -Adrian
>
>
> On 3/2/2011 3:37 AM, Gilles Sadowski wrote:
>
>> In my view, the
>> exceptions are good if they allow to easily track down bugs (be they in CM
>> or in user code). Accordingly they must precisely point to the source of
>> the
>> problem (in the code) and not try to outguess the user (as to what it
>> should mean for him).
>>
>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [ALL] @authors tags

[Paul Benedict]

FYI

http://mail-archives.apache.org/mod_mbox/jakarta-jmeter-dev/200402.mbox/%3c4039f65e.7020...@atg.com%3E

Paul

On Mon, Apr 4, 2011 at 6:49 PM, Gary Gregory  wrote:

> On Apr 4, 2011, at 17:23, 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.
>
> Fine with me.
> Gary
>
> >
> > Phil
> >> cheers,
> >> Torsten
> >>
> >> -
> >> 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] @version tag :)

[Paul Benedict]

The only benefit of the @version tag is that it shows up in javadoc. The
$Id$, if at the top of the file, does not. It's nice to see the subversion
number in API documents. I prefer that since it lets me track down the
actual version in a repository.

Paul

On Tue, Apr 5, 2011 at 8:58 AM, Gary Gregory  wrote:

> On Tue, Apr 5, 2011 at 6:19 AM, sebb  wrote:
>
> > On 5 April 2011 10:44, sebb  wrote:
> > > On 5 April 2011 09:55, Simone Tripodi 
> wrote:
> > >> Hi all guys!
> > >>
> > >> @Torsten: I agree, question is that I have never understood why the
> > >> common usage is putting SVN tags in @version javadoc, so since I
> > >> noticed a mixed usage, I wondered which one is the commonly used;
> > >>
> > >> @Christian: I intended @version, because existing source have *a lot*
> > >> of that tag; for @since instead the common usage seems to be correct
> > >>
> > >> BTW I would be +1 for NO @version and putting only @since
> > >
> > > I think the intention of the @version tag is to identify code that is
> > > not stored in SVN - e.g. in a source archive.
> > >
> > > $Revision$ and $Id$ (or even $HeadUrl) are fine in @version comments,
> > > however please don't use $Date$ as that is expressed in local time.
> > > This really messes up release checking as the dates in source archives
> > > don't match the dates in SVN tag checkouts unless the same timezone is
> > > being used.
> >
> > In case it's not obvious, I am
> >
> > -1 to banning @version, as it can be useful
> >
>
> Since $Id$ contains the user ID we I would an @version that contains the
> revision number. I find that useful. I like to see a revision number in the
> manifest too (if it's not there already), like
>
> http://maven.apache.org/plugin-developers/cookbook/add-svn-revision-to-manifest.html
>
> Gary
>
>
> > +1 to banning $Date$ in @version
> >
> > -
> > 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
>

Re: [ALL] @authors tags

[Paul Benedict]

I thought I sent this link previously, but I can no longer such an email:
http://mail-archives.apache.org/mod_mbox/jakarta-jmeter-dev/200402.mbox/%3c4039f65e.7020...@atg.com%3E

Does anyone have thoughts on this? This is the rule I thought Apache was
following across the board, which is to remove @author tags so that
contributors have better protection.

I am not aware the policy changed. If so, please let me know.

Paul

On Tue, Apr 5, 2011 at 3:13 PM, Henri Yandell  wrote:

> 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: [lang] Pair vs. [collection] org.apache.commons.collections.keyvalue

[Paul Benedict]

I think "tuple" is a better package name. In geo-coordinates, I don't think
it's proper to call Longtitude a key and Latitude a value. It's just a tuple
of values. Same thing for 3d dimension space, etc.

On Tue, Apr 12, 2011 at 12:33 PM, Gary Gregory wrote:

> On Tue, Apr 12, 2011 at 12:16 PM, Stephen Colebourne
> wrote:
>
> > On 12 April 2011 17:10, Matt Benson  wrote:
> > > On Tue, Apr 12, 2011 at 10:20 AM, Stephen Colebourne
> > >  wrote:
> > >> The [collections] KeyValue class was a mistake. [lang] Pair is a
> > >> better more general concept.
> > >>
> > >> The only thing I'd consider with [lang] Pair now is whether it should
> > >> move to its own package, in case it grows later (primitive versions).
> > >>
> > >
> > > oacl.tuple?
> >
> > +1
>
> Gary
>
>
> > If we create a package, that would be the name I'd choose.
> > Stephen
> >
> > -
> > 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
>

Re: [ALL] use lazy consensus voting for Commons Parent releases in future

[Paul Benedict]

-1

POM changes can have big impacts, especially if an erroneous one is
released. It's not that I don't trust the person who makes the changes, but
I would like several people to approve the changes before the ecosystem is
impacted. Checks and balances.

If it turns out I am the only -1 vote, I will remove my vote :-)

Paul

On Mon, Apr 18, 2011 at 4:40 PM, sebb  wrote:

> As suggested by Hen, we should be able to use lazy consensus voting
> for Commons Parent pom releases.
>
> [ ] +1 let's use lazy consensus voting for Commons Parent pom in future
> [ ] -1 why not?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [ALL] use lazy consensus voting for Commons Parent releases in future

[Paul Benedict]

Here is Apache's Release FAQ:
http://www.apache.org/dev/release.html

There is a line that says "Each PMC must obey the ASF requirements on
approving any release" but then doesn't divulge those rules. I imagine the
+3 rules applies universally. If they don't, I am about to learn something
new.

Paul

On Tue, Apr 19, 2011 at 9:00 AM, Mark Thomas  wrote:

> On 18/04/2011 22:40, sebb wrote:
> > As suggested by Hen, we should be able to use lazy consensus voting
> > for Commons Parent pom releases.
> >
> > [ ] +1 let's use lazy consensus voting for Commons Parent pom in future
> > [X] -1 why not?
>
> It is a release and that requires a positive action from the PMC to
> approve the release to ensure the necessary legal protection for the
> release manager is in place.
>
> It appears that Commons Parent is released to Maven central but not to
> the standard ASF /dist location. That needs to be corrected. All
> releases must be released via the standard ASF /dist location to ensure
> that releases are correctly archived.
>
> That Commons parent is only intended for use as a dependency by other
> Commons components is irrelevant. It is released therefore the standard
> rules regarding releases must be adhered to.
>
> Mark
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: svn commit: r1094856 - /commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java

[Paul Benedict]

100% agreement with Torsten I carried my Effective Java 2nd Edition book
in to work today.

It's item #7. On Page 29 says, Josh says, "While there is no guarantee
that the finalizer will be invoked promptly, it may be better to free the
resource
late than never, in those (hopefully rare) cases where the client fails to
call
the explicit termination method. But the finalizer should log a warning if
it
finds that the resource has not been terminated"

On Tue, Apr 19, 2011 at 10:13 AM, sebb  wrote:

> On 19 April 2011 16:00, Torsten Curdt  wrote:
> > I am really not comfortable doing all this stuff in finalize. Why use
> > finalize at all?
> > If someone forgot a close then he has to find and fix this in his code.
> >
> > Darn. Cannot find the reference I am thinking of why using "finalize"
> > usually is really a bad idea. Was it from Bloch? Can't remember.
>
> Bloch does say that generally finalizers should not be used..
>
> However, he does say that they can be useful for "safety nets" in case
> the object owner forgets to terminate it.
> Better late than never.
> In which case he says the finalizer should log a warning if the
> resource has not been correctly terminated.
>
> This is exactly what we are doing here.
>
> > cheers,
> > Torsten
> >
> > -
> > 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: svn commit: r1094856 - /commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java

[Paul Benedict]

Sorry, 100% agreement with sebb. I read the attribution wrong :-)

On Tue, Apr 19, 2011 at 10:26 AM, Paul Benedict wrote:

> I carried my Effective Java 2nd Edition book in to work today.
>
> It's item #7. On Page 29 says, Josh says, "While there is no guarantee
> that the finalizer will be invoked promptly, it may be better to free the
> resource
> late than never, in those (hopefully rare) cases where the client fails to
> call
> the explicit termination method. But the finalizer should log a warning if
> it
> finds that the resource has not been terminated"
>
>
> On Tue, Apr 19, 2011 at 10:13 AM, sebb  wrote:
>
>> On 19 April 2011 16:00, Torsten Curdt  wrote:
>> > I am really not comfortable doing all this stuff in finalize. Why use
>> > finalize at all?
>> > If someone forgot a close then he has to find and fix this in his code.
>> >
>> > Darn. Cannot find the reference I am thinking of why using "finalize"
>> > usually is really a bad idea. Was it from Bloch? Can't remember.
>>
>> Bloch does say that generally finalizers should not be used..
>>
>> However, he does say that they can be useful for "safety nets" in case
>> the object owner forgets to terminate it.
>> Better late than never.
>> In which case he says the finalizer should log a warning if the
>> resource has not been correctly terminated.
>>
>> This is exactly what we are doing here.
>>
>> > cheers,
>> > Torsten
>> >
>> > -
>> > 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: [POOL2] Java 1.5 or 1.6?

[Paul Benedict]

Is it too radical to suggest POOL 2 be 1.5 and POOL 3 be 1.6? Just
bump up major version every time you target a new major JDK.

On Fri, May 6, 2011 at 10:35 AM, Mark Thomas  wrote:
> On 06/05/2011 16:24, Phil Steitz wrote:
>> On 5/6/11 3:43 AM, Mark Thomas wrote:
>>> Before I go too far down the road of the re-writing the core object
>>> allocation code for pool2, I'd like to get some clarity on what the
>>> minimum Java version targeted by pool2 should be.
>>
>> It is also logical to ask at this point if the rewrite is desirable
>> / necessary and what we expect to gain from it.  I have pretty
>> consistently advocated this, but given the work and inevitable
>> stabilization required, we should at least ask the question.  Seems
>> to me the goals should be 0) performance 1) maintainability 2)
>> robustness 3) (configurable?) fairness.  Do you agree with these and
>> are you sure the rewrite is necessary to get them?
>
> Yes I agree. To address 0), we need to remove most/all of the
> synchronisation around object allocation. That means a re-write, almost
> certainly with java.u.c. I still have concerns around 1) & 2). The more
> I think about this problem, the more I realise I need to spend more time
> thinking about the problem. At the moment, I would rather take the time
> and get this right.
>
>>> It is currently 1.5.
>>>
>>> It would make the implementation of the FIFO/LIFO allocation option
>>> considerably easier if that was changed to 1.6.
>>
>> Can you explain a little what the problem is?
>
> Sure. In pool1 we have the ability (via CursorableLinkedList) to remove
> and insert idle objects at any point in the queue. We use this for the
> evictor and idle validation. It we switch to java.u.c (and I think it is
> almost certain we will have to to get the performance we want) there are
> far fewer options over object insertion/creation.
>
> In Java 1.5, LinkedBlockingQueue only supports FIFO. It is not possible
> to remove from the tail of the queue or insert at the head. That makes
> LIFO pretty much impossible to implement.
>
> In Java 1.6, LinkedBlockingDeque allows inserts and removals at either
> end of the queue. That solves the LIFO/FIFO issue but not the eviction /
> idle validation questions. I have some ideas about this but I am trying
> to avoid creating lots of complexity. I am also mulling over how to
> ensure that maxActive and friends are adhered to.
>
> Mark
>
>
>
> -
> 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: [OGNL] startup questions

[Paul Benedict]

Would you guys be willing to start at 4.0-SNAPSHOT so there's a direct
continuation of versioning? Just a novel thought since it might help
others to see it's not a re-invention of OGNL, per se, but the
continuation of it.

On Wed, May 11, 2011 at 8:38 AM, Gary Gregory  wrote:
> On May 11, 2011, at 9:36, Jochen Wiedmann  wrote:
>
>> On Wed, May 11, 2011 at 2:28 PM, sebb  wrote:
>>
>>> I'd be inclined to keep the current package name and Maven ids during
>>> (most of) incubation.
>>
>> Disagreed. Changing package names etc. should be the first steps in
>> incubation. As should be the publication of an early release with the
>> new package names. This allows end users to pick up as soon as
>> possible while still be upwards compatible.
>
> +1
> Gary
>
>>
>> If you don't do that, then users might prefer to wait "until the major
>> change is done".
>>
>>
>>
>> --
>> 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
>
>

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

Re: [LANG] Is a Range a kind of Pair?

[Paul Benedict]

Is it wrong to assume that a Range is always a 2-dimensional set? Can
ranges ever be Nth dimensional?

On Thu, May 19, 2011 at 8:41 AM, Gary Gregory  wrote:
> On Wed, May 18, 2011 at 1:03 PM, Matthew Pocock <
> turingatemyhams...@gmail.com> wrote:
>
>> Range is not a sub-type of pair. You can think of a pair as being an
>> ordered
>> set of 2 items. A Range is a contiguous set defined by a lower and upper
>> bound (which may or may not be inclusive). Given some flag
>> Clusive=Inclusive|Exclusive, then every range is uniquely identified by a
>> single Pair>. The in-memory representation of the
>> data defining a pair and a range may be the same, but they are not at all
>> the same kind of thing.
>>
>
> I understand the semantic difference, but to me the representation is the
> same, unless you get in the Iterable game (see below.) But it does now feel
> -- with your clear explanation, thank you -- that they are different beasts.
>
> The Inclusive|Exclusive part is not in the code so that does not feel like a
> fair argument to support the difference though.
>
> If "a Range is a contiguous set" (a "list" since a set is not ordered), then
> it would make sense to support Iterable so you can use it in a for-each
> loop, this can be post 3.0 (the remove method in Iterator might be an
> issue.)
>
> Gary
>
>
>>
>> Matthew
>>
>> On 18 May 2011 17:46, Matt Benson  wrote:
>>
>> > On Wed, May 18, 2011 at 11:32 AM, Gary Gregory 
>> > wrote:
>> > > Why doesn't a Range does extend Pair? It's pretty clear (to me at
>> least)
>> > > that a range is a pair of values.
>> > >
>> > > Because the Pair is in our tuple package, it means that it should
>> follow
>> > > tuple logic and be thought of as an ordered list of elements, in this
>> > case
>> > > two elements.
>> > >
>> > > The methods that Range has that are not in Pair could be moved there.
>> > >
>> >
>> > IMHO a Range is not precisely a Pair, though it could define its
>> > _limits_ in those terms.
>> >
>> > Matt
>> >
>> > > --
>> > > 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
>> >
>> >
>>
>>
>> --
>> Matthew Pocock
>> mailto: turingatemyhams...@gmail.com
>> gchat: turingatemyhams...@gmail.com
>> msn: matthew_poc...@yahoo.co.uk
>> irc.freenode.net: drdozer
>> (0191) 2566550
>>
>
>
>
> --
> 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: Rejoin the PMC...

[Paul Benedict]

Or is it like having a new grandchild? ... and you get to say, "hey, i
get to be a grandpa again!"

On Tue, May 24, 2011 at 9:40 AM, James Carman
 wrote:
> On Tue, May 24, 2011 at 6:11 AM, Siegfried Goeschl
>  wrote:
>> But it is good to see the all the "grandpa's" returning  :-)
>>
>
> I would like to publicly say that I resent this "grandpa" moniker
> before I get permanently labeled that way! :)
>
> -
> 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] RC4 heads up

[Paul Benedict]

You sure it's not a bug in the JDK? Just asking. The results are curious.

On Tue, Jul 12, 2011 at 5:52 PM, Stephen Colebourne
 wrote:
> On 12 July 2011 18:56, Jörg Schaible  wrote:
>> 1/ FastDateFormat
>> The date format " yyy yy y" is formatted with JDK 7 as "2003 2003 03
>> 2003" instead of "2003 03 03 03". So, should FastDateFormat follow the JDK
>> in any case and adjust its result according the runtime? Interestingly
>> Javadoc states already for Java 6: "For formatting, if the number of pattern
>> letters is 2, the year is truncated to 2 digits; otherwise it is interpreted
>> as a number."
>
> I think that since this release is not compatible with previous
> releases, then [lang] should follow JDK 7 conventions only, with good
> javadoc about what it does.
>
> 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: [RESULT] [LANG] Release Commons Lang 3.0 (based on RC4)

[Paul Benedict]

Congrats! Long Live Commons Lang 3.

On Tue, Jul 19, 2011 at 4:02 AM, Simone Tripodi
 wrote:
> Great achievement Henri,
> and congrats for the release!!!
> I'm so sorry I didn't take part to the review process but honestly not
> being familiar with Lang I was a little worried on influencing both
> positively/negatively the vote.
> I'll do my best to help more next time!
> Have a nice day, all the best!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Tue, Jul 19, 2011 at 10:52 AM, Henri Yandell  wrote:
>> On Mon, Jul 18, 2011 at 6:37 PM, Henri Yandell  wrote:
>>> Vote passes [!]
>>>
>>> 6 +1s.
>>>
>>> Gary Gregory
>>> Matt Benson
>>> Oliver Heger
>>> Jörg Schaible
>>> Stephen Colebourne
>>> and my own implicit +1.
>>>
>>> I'll start dredging up the 'how to push a release' knowledge tonight :)
>>
>> Status:
>>
>>    Tag copied over.
>>    Distributions uploaded. Synced on Apache machines, propagating out
>> to mirrors.
>>    Maven contents in the sync directory, waiting to show up on maven.org.
>>    Website updated (including Jörg's suggestions). Sync pending.
>>    Released in JIRA.
>>
>> Waiting on maven.org and the mirrors before announcing.
>>
>> 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] [LANG] Release Commons Lang 3.0 (based on RC4)

[Paul Benedict]

As long as Commons IO is marked as a test dependency, I am okay with
it. I just don't want it to be a compile-time dependency for the main
source.

On Tue, Jul 19, 2011 at 8:24 AM, Gary Gregory  wrote:
> On Mon, Jul 18, 2011 at 9:25 PM, Henri Yandell  wrote:
>
>> Interesting issue; though thankfully it's post RC4 so not an issue wrt
>> releasing 3.0.
>>
>> Assuming (for argument's sake) that IO Test depends on Lang & Lang
>> Test depends on IO; is this bad? I'm not convinced it is. Dealing with
>> something like that is something the build system needs to know how to
>> do.
>>
>
> We depend on JUnit and EasyMock for testing, so I really think it is OK to
> also depend on [io] for testing as well. C&P'ing code is lame in this case
> IMO.
>
> Gary
>
>
>> Hen
>>
>> On Mon, Jul 18, 2011 at 3:50 PM, Stephen Colebourne
>>  wrote:
>> > StringEscapeUtils test includes IOUtils, which it shouldn't. (If its
>> > been added as a dependency, then it needs to be removed, even for
>> > testing)
>> >
>> > Stephen
>> >
>> > On 18 July 2011 23:41, Gary Gregory  wrote:
>> >> On Jul 18, 2011, at 18:36, Stephen Colebourne 
>> wrote:
>> >>
>> >>> I'm willing to vote +1
>> >>> Although I haven't checked every recent change, but AFAIK recent
>> >>> changes have been minor and my previous issues are resolved.
>> >>>
>> >>> I would note that the svn as of right now does not compile, due to an
>> >>> IOUtils reference that shouldn't be
>> >>
>> >> Hi Stephen,
>> >>
>> >> Can you specify what your error is? I check both the maven and ant
>> >> builds before my commit.
>> >>
>> >> Gary
>> >>
>> >>>
>> >>> Stephen
>> >>>
>> >>>
>> >>> On 16 July 2011 01:18, Henri Yandell  wrote:
>>  Thanks Gary.
>> 
>>  So 4 +1s.
>> 
>>  Stephen, Niall, Paul, Phil, Sebb, James - nudge to consider voting
>>  (apologies if I missed anyone else who has committed to Lang 3.0)?
>> 
>>  Hen
>> 
>>  On Fri, Jul 15, 2011 at 12:32 PM, Gary Gregory <
>> garydgreg...@gmail.com> wrote:
>> > That's true too. In the spirit of release early, release often, I
>> remove my
>> > -1 :)
>> >
>> > Gary
>> >
>> >
>> >> On Fri, Jul 15, 2011 at 10:54 AM, Henri Yandell > >wrote:
>> >>
>> >>> Less that it is painful (though I agree that it is), more that if
>> you
>> >>> hold up a release for every bug that comes in then you continually
>> sit
>> >>> in a non-releasing state. We have a really bad habit of that in
>> >>> Commons, constantly polishing and polishing before a release.
>> >>>
>> >>> Hen
>> >>>
>> >>> On Fri, Jul 15, 2011 at 6:58 AM, Gary Gregory <
>> garydgreg...@gmail.com>
>> >>> wrote:
>>  Here is my main issue: we are releasing a major new version and
>> there is
>> >>> a
>>  known bug reported by a user which has been fixed in SVN. It feels
>> like
>> >>> we
>>  are unwilling to cut a new RC because our build process and
>> validation
>> >>> is
>>  painful (it is so in my experience at least, your mileage may vary
>> using
>>  custom scripts, Nexus, or other incantations.) This is not a good
>> reason
>> >>> IMO
>>  to avoid rebuilding. In the case of a major release like 3.0, I do
>> not
>> >>> want
>>  to leave a bad taste in a user's mouth with a class that is not
>> fully
>> >>> baked,
>>  especially in code new to 3.0. I like that we are planning a
>> 3.0.1, but
>> >>> I do
>>  not see why we should not include something that is already fixed
>> for
>> >>> 3.0.
>>  It's not like this issue needs more time on investigating, coding,
>> and
>>  testing.
>> 
>>  Now, if you all really think I am being unreasonable, I'll be
>> happy to
>> >>> go
>>  with the flow and reverse -1, but for now, I wanted to express my
>> full
>> >>> POV.
>> 
>>  Thank you for reading and talking :)
>> 
>>  Gary
>> 
>>  On Fri, Jul 15, 2011 at 3:44 AM, Henri Yandell <
>> flame...@gmail.com>
>> >>> wrote:
>> >
>> > Waiting on you to determine whether your -1 is still there on
>> LANG-720.
>> >
>> > Then need to poke Niall, Stephen et al to do a review :)
>> >
>> > On Thu, Jul 14, 2011 at 11:54 AM, Gary Gregory <
>> garydgreg...@gmail.com
>> 
>> > wrote:
>> >> -1, let's pick up the committed fix for
>> >> https://issues.apache.org/jira/browse/LANG-720
>> >>
>> >> I recall seeing traffic in the escape/unescape area so it makes
>> sense
>> >>> to
>> >> polish this new code as much as possible IMO.
>> >>
>> >> Gary
>> >>
>> >> On Thu, Jul 14, 2011 at 12:47 AM, Henri Yandell <
>> flame...@gmail.com>
>> >> wrote:
>> >>
>> >>> Lang is ready to consider 3.0 release again.
>> >>>
>> >>> RC4 is available here:
>

Re: [lang] IOUtils in tests [Re: [VOTE] [LANG] Release Commons Lang 3.0 (based on RC4)]

[Paul Benedict]

Goo to know. If IO is imported just for one test case, then +1 for
Stephen's suggestion. Copy the code and shrink the dependency graph.

On Tue, Jul 19, 2011 at 9:47 AM, Stephen Colebourne
 wrote:
> Personally, I'm OK with using JUnit and mocking utilities as they are
> both specifically intended for testing. I think using IOUtils in
> testing [lang] is distinctly dubious, especially for a single method,
> and I'd much rather see the code copied. This isn't a -1 veto, but its
> a strong disapproval.
>
> Stephen
>
>
> On 19 July 2011 15:13, Gary Gregory  wrote:
>> On Tue, Jul 19, 2011 at 9:28 AM, Paul Benedict  wrote:
>>
>>> As long as Commons IO is marked as a test dependency, I am okay with
>>> it. I just don't want it to be a compile-time dependency for the main
>>> source.
>>>
>>
>> It is specified in the test scope in the POM.
>>
>> Gary
>>
>>
>>>
>>> On Tue, Jul 19, 2011 at 8:24 AM, Gary Gregory 
>>> wrote:
>>> > On Mon, Jul 18, 2011 at 9:25 PM, Henri Yandell 
>>> wrote:
>>> >
>>> >> Interesting issue; though thankfully it's post RC4 so not an issue wrt
>>> >> releasing 3.0.
>>> >>
>>> >> Assuming (for argument's sake) that IO Test depends on Lang & Lang
>>> >> Test depends on IO; is this bad? I'm not convinced it is. Dealing with
>>> >> something like that is something the build system needs to know how to
>>> >> do.
>>> >>
>>> >
>>> > We depend on JUnit and EasyMock for testing, so I really think it is OK
>>> to
>>> > also depend on [io] for testing as well. C&P'ing code is lame in this
>>> case
>>> > IMO.
>>> >
>>> > Gary
>>> >
>>> >
>>> >> Hen
>>> >>
>>> >> On Mon, Jul 18, 2011 at 3:50 PM, Stephen Colebourne
>>> >>  wrote:
>>> >> > StringEscapeUtils test includes IOUtils, which it shouldn't. (If its
>>> >> > been added as a dependency, then it needs to be removed, even for
>>> >> > testing)
>>> >> >
>>> >> > Stephen
>>> >> >
>>> >> > On 18 July 2011 23:41, Gary Gregory  wrote:
>>> >> >> On Jul 18, 2011, at 18:36, Stephen Colebourne 
>>> >> wrote:
>>> >> >>
>>> >> >>> I'm willing to vote +1
>>> >> >>> Although I haven't checked every recent change, but AFAIK recent
>>> >> >>> changes have been minor and my previous issues are resolved.
>>> >> >>>
>>> >> >>> I would note that the svn as of right now does not compile, due to
>>> an
>>> >> >>> IOUtils reference that shouldn't be
>>> >> >>
>>> >> >> Hi Stephen,
>>> >> >>
>>> >> >> Can you specify what your error is? I check both the maven and ant
>>> >> >> builds before my commit.
>>> >> >>
>>> >> >> Gary
>>> >> >>
>>> >> >>>
>>> >> >>> Stephen
>>> >> >>>
>>> >> >>>
>>> >> >>> On 16 July 2011 01:18, Henri Yandell  wrote:
>>> >> >>>> Thanks Gary.
>>> >> >>>>
>>> >> >>>> So 4 +1s.
>>> >> >>>>
>>> >> >>>> Stephen, Niall, Paul, Phil, Sebb, James - nudge to consider voting
>>> >> >>>> (apologies if I missed anyone else who has committed to Lang 3.0)?
>>> >> >>>>
>>> >> >>>> Hen
>>> >> >>>>
>>> >> >>>> On Fri, Jul 15, 2011 at 12:32 PM, Gary Gregory <
>>> >> garydgreg...@gmail.com> wrote:
>>> >> >>>>> That's true too. In the spirit of release early, release often, I
>>> >> remove my
>>> >> >>>>> -1 :)
>>> >> >>>>>
>>> >> >>>>> Gary
>>> >> >>>>>
>>> >> >>>>>
>>> >> >>>>>> On Fri, Jul 15, 2011 at 10:54 AM, Henri Yandell <
>>> flame...@gmail.com
>>> >> >wrote:
>>>

Re: [lang] IOUtils in tests [Re: [VOTE] [LANG] Release Commons Lang 3.0 (based on RC4)]

[Paul Benedict]

Gary,

I think it's about intention. If you have intentions of further
expanding the user of Commons IO in test cases, I think it makes sense
to use it as a dependency. But if it is simply a one-off without plans
of further use, then I would copy the method.

Paul

On Tue, Jul 19, 2011 at 10:26 AM, Gary Gregory  wrote:
> HI All:
>
> I do not understand the general reluctance to reuse code in a clean way
> through jars, especially in this case for tests.
>
> I shake my head every time I open the search type dialog in Eclipse for my
> (larger) work projects and see a dozen StringUtils classes (half of them in
> org.apache).
>
> I understand that each project is independent and so on, but my hope is that
> [commons] as one project could at least eat its own dog food.
>
> Gary
>
> On Tue, Jul 19, 2011 at 10:47 AM, Stephen Colebourne
> wrote:
>
>> Personally, I'm OK with using JUnit and mocking utilities as they are
>> both specifically intended for testing. I think using IOUtils in
>> testing [lang] is distinctly dubious, especially for a single method,
>> and I'd much rather see the code copied. This isn't a -1 veto, but its
>> a strong disapproval.
>>
>> Stephen
>>
>>
>> On 19 July 2011 15:13, Gary Gregory  wrote:
>> > On Tue, Jul 19, 2011 at 9:28 AM, Paul Benedict 
>> wrote:
>> >
>> >> As long as Commons IO is marked as a test dependency, I am okay with
>> >> it. I just don't want it to be a compile-time dependency for the main
>> >> source.
>> >>
>> >
>> > It is specified in the test scope in the POM.
>> >
>> > Gary
>> >
>> >
>> >>
>> >> On Tue, Jul 19, 2011 at 8:24 AM, Gary Gregory 
>> >> wrote:
>> >> > On Mon, Jul 18, 2011 at 9:25 PM, Henri Yandell 
>> >> wrote:
>> >> >
>> >> >> Interesting issue; though thankfully it's post RC4 so not an issue
>> wrt
>> >> >> releasing 3.0.
>> >> >>
>> >> >> Assuming (for argument's sake) that IO Test depends on Lang & Lang
>> >> >> Test depends on IO; is this bad? I'm not convinced it is. Dealing
>> with
>> >> >> something like that is something the build system needs to know how
>> to
>> >> >> do.
>> >> >>
>> >> >
>> >> > We depend on JUnit and EasyMock for testing, so I really think it is
>> OK
>> >> to
>> >> > also depend on [io] for testing as well. C&P'ing code is lame in this
>> >> case
>> >> > IMO.
>> >> >
>> >> > Gary
>> >> >
>> >> >
>> >> >> Hen
>> >> >>
>> >> >> On Mon, Jul 18, 2011 at 3:50 PM, Stephen Colebourne
>> >> >>  wrote:
>> >> >> > StringEscapeUtils test includes IOUtils, which it shouldn't. (If
>> its
>> >> >> > been added as a dependency, then it needs to be removed, even for
>> >> >> > testing)
>> >> >> >
>> >> >> > Stephen
>> >> >> >
>> >> >> > On 18 July 2011 23:41, Gary Gregory 
>> wrote:
>> >> >> >> On Jul 18, 2011, at 18:36, Stephen Colebourne <
>> scolebou...@joda.org>
>> >> >> wrote:
>> >> >> >>
>> >> >> >>> I'm willing to vote +1
>> >> >> >>> Although I haven't checked every recent change, but AFAIK recent
>> >> >> >>> changes have been minor and my previous issues are resolved.
>> >> >> >>>
>> >> >> >>> I would note that the svn as of right now does not compile, due
>> to
>> >> an
>> >> >> >>> IOUtils reference that shouldn't be
>> >> >> >>
>> >> >> >> Hi Stephen,
>> >> >> >>
>> >> >> >> Can you specify what your error is? I check both the maven and ant
>> >> >> >> builds before my commit.
>> >> >> >>
>> >> >> >> Gary
>> >> >> >>
>> >> >> >>>
>> >> >> >>> Stephen
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> On 16 July 2011 01:18, Henri Yan

Re: [LANG] Commons Lang 3.0

[Paul Benedict]

Yes. The reason the package name was changed was so that 1.x-2.x and
3.0 can coexist together in an application. Since Commons
Configuration relies on a previous version, as Stephen said, you will
need both dependencies.

On Wed, Jul 27, 2011 at 7:53 AM, Stephen Colebourne
 wrote:
> You will need both versions of commons-lang, the new and the old.
> Stephen
>
> On 27 July 2011 11:17, Rohan Kadam  wrote:
>> Hi All,
>>
>> We have upgraded our common lang jar to 3.0 version. We have replaced 
>> package name "lang" to "lang3". But since it has already been mentioned on 
>> apache website that Common Lang 3.0 is not backward compatible, we are 
>> facing some compilation issues.
>>
>> After replacing Apache Commons Lang 2.1 with Apache Commons Lang 3.0 we get 
>> some compilation errors since the class 
>> org.apache.commons.lang.exception.NestableException is being referred 
>> internally in the class files of  
>> org.apache.commons.configuration.ConfigurationException.
>>
>> To summarize the common lang jar to 3.0 version is not compatible with 
>> common configuration jar latest version.
>>
>> Please suggest.
>>
>> Thanks.
>>
>> "Legal Disclaimer: This electronic message and all contents contain 
>> information from Cybage Software Private Limited which may be privileged, 
>> confidential, or otherwise protected from disclosure. The information is 
>> intended to be for the addressee(s) only. If you are not an addressee, any 
>> disclosure, copy, distribution, or use of the contents of this message is 
>> strictly prohibited. If you have received this electronic message in error 
>> please notify the sender by reply e-mail to and destroy the original message 
>> and all copies. Cybage has taken every reasonable precaution to minimize the 
>> risk of malicious content in the mail, but is not liable for any damage you 
>> may sustain as a result of any malicious content in this e-mail. You should 
>> carry out your own malicious content checks before opening the e-mail or 
>> attachment."
>> www.cybage.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
>
>

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

Re: [LANG] Commons Lang 3.0

[Paul Benedict]

You know, it would probably be nice for our end users to note what
this email contained for our home page:

1) A clear explanation that Commons Lang 3 and 2/1 can co-exist side
by side and that upgrading to 3 doesn't mean you won't still need
previous versions.
2) What we know other Apache Commons depend on 2.x

Paul

On Wed, Jul 27, 2011 at 10:41 AM, Matt Benson  wrote:
> Or maybe I won't hit [flatfile], since I see you've just done so.  ;)  Thanks!
>
> Matt
>
> On Wed, Jul 27, 2011 at 10:40 AM, Matt Benson  wrote:
>> Good point.  I'll go ahead and update [flatfile].  IIRC the proxy 2
>> branch already uses [lang] 3; I'll update that to use the release.
>>
>> Matt
>>
>> On Wed, Jul 27, 2011 at 10:32 AM, Henri Yandell  wrote:
>>> For the record, and so we can consider what needs a release, the
>>> following components depend on Lang:
>>>
>>> * Chain
>>> * Configuration
>>> * JCS
>>> * Proxy
>>>
>>> and in the Sandbox:
>>>
>>> * Flatfile
>>> * Pipeline
>>>
>>> Hen
>>>
>>> On Wed, Jul 27, 2011 at 6:13 AM, Paul Benedict  wrote:
>>>> Yes. The reason the package name was changed was so that 1.x-2.x and
>>>> 3.0 can coexist together in an application. Since Commons
>>>> Configuration relies on a previous version, as Stephen said, you will
>>>> need both dependencies.
>>>>
>>>> On Wed, Jul 27, 2011 at 7:53 AM, Stephen Colebourne
>>>>  wrote:
>>>>> You will need both versions of commons-lang, the new and the old.
>>>>> Stephen
>>>>>
>>>>> On 27 July 2011 11:17, Rohan Kadam  wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> We have upgraded our common lang jar to 3.0 version. We have replaced 
>>>>>> package name "lang" to "lang3". But since it has already been mentioned 
>>>>>> on apache website that Common Lang 3.0 is not backward compatible, we 
>>>>>> are facing some compilation issues.
>>>>>>
>>>>>> After replacing Apache Commons Lang 2.1 with Apache Commons Lang 3.0 we 
>>>>>> get some compilation errors since the class 
>>>>>> org.apache.commons.lang.exception.NestableException is being referred 
>>>>>> internally in the class files of  
>>>>>> org.apache.commons.configuration.ConfigurationException.
>>>>>>
>>>>>> To summarize the common lang jar to 3.0 version is not compatible with 
>>>>>> common configuration jar latest version.
>>>>>>
>>>>>> Please suggest.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> "Legal Disclaimer: This electronic message and all contents contain 
>>>>>> information from Cybage Software Private Limited which may be 
>>>>>> privileged, confidential, or otherwise protected from disclosure. The 
>>>>>> information is intended to be for the addressee(s) only. If you are not 
>>>>>> an addressee, any disclosure, copy, distribution, or use of the contents 
>>>>>> of this message is strictly prohibited. If you have received this 
>>>>>> electronic message in error please notify the sender by reply e-mail to 
>>>>>> and destroy the original message and all copies. Cybage has taken every 
>>>>>> reasonable precaution to minimize the risk of malicious content in the 
>>>>>> mail, but is not liable for any damage you may sustain as a result of 
>>>>>> any malicious content in this e-mail. You should carry out your own 
>>>>>> malicious content checks before opening the e-mail or attachment."
>>>>>> www.cybage.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
>>>>>
>>>>>
>>>>
>>>> -
>>>> 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: [chain] Forking to a 2.0?

[Paul Benedict]

+1. I have done some of this privately (like generics). Having an
official version would be so useful.

On Wed, Jul 27, 2011 at 10:46 PM, Elijah Zupancic  wrote:
> Hi,
>
> I've been a active user for a number of years now and a big fan of the
> project. I'm a total beginner when it comes to contributing on Apache
> projects, so please bear with me.
>
> The code base for Apache Chain is starting to feel more and more
> dated. I would like to see the following changes in the project:
>
> * Upgrading the source code to 1.6.
> * Supporting generics on commands, so that we get something like
> Command
> * Switching the logging API over to SLF4J, so that we can swap out
> logging implementations
> * Using the new java.util.concurrency classes to handle thread safety as 
> needed.
> * Removing deprecated methods.
>
> I realize that I am suggestion rather drastic API changes that may
> break the existing API and that is why I'm suggesting a 2.0. I have a
> prototype that I am working on and I do not see it being a lot of work
> to accomplish the above tasks.
>
> Would a 2.0 version of Chain be useful to anyone? Or should I just
> fork the project for my own needs and release it independently like
> the Commons Collections with Generics?
>
> I know that I'm assuming a lot and diving in head first here, so thank
> you ahead of time for any replies.
>
> -Elijah Zupancic
>
> -
> 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: [chain] Forking to a 2.0?

[Paul Benedict]

On Thu, Jul 28, 2011 at 2:01 PM, Simone Tripodi
 wrote:
>  * please don't migrate to slf4j. here at commons we continue using
> commons-logging

I haven't heard this before. How come? Just curious.

Paul

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

Re: [logging] logging vs slf4j

[Paul Benedict]

Good deal Ralph! Didn't the creator of Log4j abandon the 1.2/1.3
branch to make SLF4J? Anyways, I have no idea why all the creativity
for logging went outside of Apache, but I would definitely like to see
a version 2.0.

You taking feature requests yet in JIRA? :-)

Paul

On Thu, Jul 28, 2011 at 7:25 PM, Ralph Goers  wrote:
> FWIW, I have been working heavily on Log4J version 2 and would hope you'd 
> help with that before going to SLF4J [1]. I have separated the API and Impl 
> in a manner similar to SLF4J/Logback but am working to correct some problems 
> I've encountered using each of those where I work.
>
> Ralph
>
> [1] 
> https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/
>
>
> On Jul 28, 2011, at 1:01 PM, Henri Yandell wrote:
>
>> Personally I'm happy for commons-logging to die. :)
>>
>> On Thu, Jul 28, 2011 at 12:19 PM, Simone Tripodi
>>  wrote:
>>> Hi all guys,
>>> I remember I raw a thread - not sure if I did it here at commons orI
>>> somewhere else here at apache - where specified we prefer adding
>>> [logging] as components dependency instead of slf4j...
>>> Did I just get crazy or someone can point me to the right direction please? 
>>> :)
>>> Many thanks in advance, all the best!!!
>>> Simo
>>>
>>> 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
>>>
>>>
>>
>> -
>> 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: [logging] logging vs slf4j

[Paul Benedict]

Would there be any merit in combining the log4j and commons logging
code? Given a hypothetical Log4j 2 and JCL 2, how much different could
they really be in terms of their goals and add-ins?

On Fri, Jul 29, 2011 at 4:51 AM, Gilles Sadowski
 wrote:
> Hello.
>
>> I would have done that but some of the deficiencies are in the API and I 
>> couldn't get Ceki to incorporate them.
>
> Do you have a pointer to a listing of those deficiencies?
>
>> [...]
>
>
> Thanks,
> Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

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

Re: [logging] logging vs slf4j

[Paul Benedict]

I prefer Apache driven projects when possible. If LOG4J2 takes off,
feature requests would be implemented quicker, I hope.

On Wed, Aug 3, 2011 at 9:27 AM, Ralph Goers  wrote:
>
> On Aug 3, 2011, at 6:07 AM, David Karlsen wrote:
>
>> Hasn't the time for both CL and log4j passed by? The trend nowadays seems to
>> be slf4j/logback.
>
> If you read further back in this thread you will see where I highlighted the 
> problems in Logback as well as difficulties with SLF4J. Plus, every time Ceki 
> goes on vacation everything stops.
>
> Ralph
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

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

Re: [logging] logging vs slf4j

[Paul Benedict]

On Wed, Aug 3, 2011 at 9:51 AM, Gary Gregory  wrote:
>
> I like Log4J just fine thank you very much :)
>
> I'm looking forward to 2.0.
>
> Gary
>

I concur with Gary. All my apps use LOG4J, not JCL or SLF4J. My
dependencies do, however, but LOG4J works great minus a few
enhancements I'd like to see.

BTW, in terms of swelling community development, if LOG4J+JCL were to
merge and just become JCL2, it could have the visibility of all
Commons committers. Isn't it much more of a common component than a
separate project? I think the logging project is dysfunctional anyway
-- make it a common component if possible.

Paul

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

Re: [collections] 4.0 release path

[Paul Benedict]

Or do a pure generics release as 3.5 to satisfy that need... which
allows 4.0 to have generics plus the benefit of major refactoring if
necessary (could also be called 4.0 and 5.0).

On Wed, Aug 3, 2011 at 9:55 AM, Matt Benson  wrote:
> On Wed, Aug 3, 2011 at 9:48 AM, Gary Gregory  wrote:
>> The most important theme IMO is generics. That's what has come up at
>> work recently in fact. Everything else except showstopper bugs can
>> wait IMO.
>
> Indeed, this seems to resonate with Hen's recent treatise on
> (paraphrased) why the hell we take so long.
>
> Matt
>
>>
>> Gary
>>
>> On Wed, Aug 3, 2011 at 9:16 AM, Simone Tripodi  
>> wrote:
>>> Hi all guys,
>>> I'm (re)starting having a good slot of spare time, I volunteered to
>>> help Matt on finalizing the [collections] release, but after had a
>>> look at the open issues I think we should agree on what including and
>>> what not.
>>> Does anyone already have a good overview/idea of collections roadmap?
>>> Many thanks in advance, have a nice day!!!
>>> Simo
>>>
>>> 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

Re: [logging] logging vs slf4j

[Paul Benedict]

On Mon, Aug 8, 2011 at 2:03 PM, Raman Gupta  wrote:
> Perhaps I'm missing something, but what exactly is wrong with simply
> using slf4j? It is an extremely simple, widely used library that
> provides out of the box hooks for many logging frameworks including
> log4j and logback, simple to configure (i.e. drop the appropriate jars
> in and thats it), and works out of the box in an OSGi environment? The
> only downside appears to be that it is not an Apache project. So what.

The biggest issue I have with SLF4J is figuring out the dependencies
that I need. I really detest having an API jar and then an
implementation/bridge jar. I find that too annoying.

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

Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]

[Paul Benedict]

I agree with sebb. I prefer an organization where everyone gets one
vote. This is obviously not the only way an organization can run, but
I like neither having a diminished or overwhelming power with my vote.
The best part of having only +1 is that you can't use your merit to
strong-arm decisions over anyone -- you have to build consensus using
reason. If you can't convince your team, the idea isn't worth doing no
matter how much more voting power you wish you had. I find this
especially equitable since there can be a split of people who do the
work (committers) and vote (PMC). There are some who commit only and
can't vote, others do commit and vote, and others who just vote. Being
on a PMC myself, I am happy my vote is equal to every one else on the
committee.

On Thu, Aug 11, 2011 at 7:00 AM, sebb  wrote:
> Why should my vote carry more weight?
>
> I may have created more SVN revisions than others, but I don't think
> that gives my vote any more value.
>
> Apart from the fact that commit count has little bearing on actual
> work done, and is not an indicator of quality, there are other ways of
> contributing (e.g. mailing list feedback, commit review, release
> testing, bug reporting) that I consider equally valuable.
>

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

Re: [vote] Graduate OGNL into Commons

[Paul Benedict]

+1

On Mon, Aug 15, 2011 at 10:19 AM, Henri Yandell  wrote:
> +1 (Commons PMC).
>
> On Mon, Aug 15, 2011 at 6:51 AM, Christian Grobmeier
>  wrote:
>> OGNL [1] has checked off all status items in the incubator.
>>
>> Most of the OGNL developers are already commons developers and the
>> risk of failure is pretty small, even without having made a release.
>> As the Commons project is already very experienced with releasing
>> components, there is no need for OGNL to learn how to do it.
>>
>> This vote is about graduating OGNL out of the incubator and proceeding
>> with it as Commons component.
>>
>> Please vote here if you are a voting as Commons committer/PMC:
>>
>> [ ] +1, graduate into Commons
>> [ ] +/-0
>> [ ] -1, don't graduate, because
>>
>> Please vote here, if you are an OGNL committer at the incubator:
>>
>> [ ] +1, graduate into Commons
>> [ ] +/-0
>> [ ] -1, don't graduate, because
>>
>> If you can vote for both parties, please do. According to the process
>> we need a vote in both teams.
>>
>> When the vote passes, a vote must be run at the Incubator project.
>> Once this passes, graduation action items can be done.
>>
>> The vote will stay open for at least 72h.
>>
>> Thanks,
>> Christian
>>
>>
>> [1] http://incubator.apache.org/projects/ognl.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
>
>

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

Re: [chain] Apache Chain v2 Proof of Concept

[Paul Benedict]

I may have missed the discussion... but are we releasing a Java 5
genericized version first before major refactoring?

On Tue, Aug 16, 2011 at 3:35 PM, Elijah Zupancic  wrote:
> Hi Simo,
>
> Yes, the patch is binary compatible with the old chain with one exception:
>
> org.apache.commons.chain.web.servlet.ServletHeaderValuesMap on line
> 97. Previously the API was returning Set Enumeration> when by all indications it actually should have
> been returning Set>. I believe that I fixed a
> previously undiscovered bug there.
>
> Right now, none of the unit tests are using generics and they all
> pass. So, I assume that we have a backwards compatible API.
>
> Thanks,
> -Elijah
>
> On Tue, Aug 16, 2011 at 2:00 AM, Simone Tripodi
>  wrote:
>> Hi Elijah,
>> looking at the patch, it seems that v2.0 is binary compatible to old
>> chain, right?
>> I mean, if in a my hypothetical application I would upgrade to v2
>> (generics a part) old code should continue working, right?
>> TIA, and count also on me!
>> All the best, have a nice day!
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Mon, Aug 15, 2011 at 6:50 PM, Elijah Zupancic  
>> wrote:
>>> Hi Matt,
>>>
>>> Thanks for the advice. I've created a JIRA issue for the patch
>>> (https://issues.apache.org/jira/browse/CHAIN-53) and signed and
>>> submitted the CLA.
>>>
>>> As for JSF, I believe I made a mistake in changing the API to use the
>>> office jsf API instead of the myfaces API that was previously being
>>> used. I went that route because I couldn't find a 2.0 version of the
>>> faces api in the Maven repo, but it looks like it is available on the
>>> myfaces project site, so I will revert the dependency to using myfaces
>>> and downgrade to 2.0.
>>>
>>> I'll start work on migrating the test cases / mocking to a newer junit
>>> and mockito, when I know that the changes will be accepted.
>>>
>>> Thanks again for the help!
>>>
>>> -Elijah
>>>
>>> On Mon, Aug 15, 2011 at 6:22 AM, Matt Benson  wrote:
 Hi, Elijah--

  I am neither a develop nor even a user of chain, so my comments will
 be high-level.  Firstly, by all means upgrade to whatever JUnit 4
 release version you like, e.g. 4.8.2.  Next, I personally am a big fan
 of Mockito, so no complaints here on that account.  I can't guarantee
 noone else would complain, but [chain] has been fairly unloved for a
 good while.  As for JSF 2.1, is there something this achieves that
 wouldn't be equally well accomplished by simply upgrading to 2.0?
 This would give [chain]'s JSF support (which I personally hadn't
 realized existed) a potentially better combination of
 doing-things-that-couldn't-easily-be-done-with-older-APIs vs. broadest
 possible applicability.

 Finally, as you don't seem to be a committer your final submission in
 this regard would be best recommended in the form of a JIRA issue, and
 your patches in (albeit large) patch form.  In addition to this, the
 scope of these changes indicates it best IMO that you submit an
 Individual Contributor License Agreement governing your contributions
 to the ASF.  See http://www.apache.org/licenses/#clas for details on
 how to do this.

 Regards and welcome,
 Matt

 On Sun, Aug 14, 2011 at 5:13 PM, Elijah Zupancic  
 wrote:
> I've just finished my proof of concept for an upgrade to Apache chain.
> I would love to get this into a svn branch. I'm not quite sure what
> the procedure is to do that, but the code can be found here for
> review:
>
> http://elijah.zupancic.name/projects/commons-chain-v2-proof-of-concept.tar.gz
>
> And here is a diff:
>
> http://elijah.zupancic.name/projects/uber-diff
>
> At a high level, I have incorporated the following features in this
> proof of concept:
>
> * Global upgrade to the JDK 1.5
> * Added @Override annotations
> * Upgraded to the Servlet 2.5 API
> * Upgraded to the Faces 2.1 API
> * Upgraded to the Portlet 2.0 API
> * Upgraded the Maven Parent POM version
> * Added generics support to Command so that Command's API looks like:
>
> public interface Command {
> ...
>    boolean execute(T context) throws Exception;
> }
>
> * Servlet and Portlet packages now provide Genericized APIs.
> * All dicey changes have been marked with a comment with my name: (elijah)
>
> More or less the work to updated Chain was straight forward albeit
> time consuming.
>
> If everyone is on board for this update, I would like to upgrade the
> test cases to use a new version of JUnit. However, this leads to a few
> questions:
>
> * What version of JUnit should I use?
> * Would it be ok to use Mockito for mocking instead of the home grown
> mocking classes already contained in the project?
>
> Please let me know what you think. Getting this

Re: [chain] Apache Chain v2 Proof of Concept

[Paul Benedict]

I misunderstood CHAIN-53 then.

On Tue, Aug 16, 2011 at 4:29 PM, Elijah Zupancic  wrote:
> Hi Paul,
>
> I haven't heard any discussion about a pending refactor to chain in
> the last month (when I proposed the patch). Could you tell me/us more
> about any plans for a major refactoring?
>
> Thanks,
> -Elijah
>
> On Tue, Aug 16, 2011 at 1:42 PM, Paul Benedict  wrote:
>> I may have missed the discussion... but are we releasing a Java 5
>> genericized version first before major refactoring?
>>
>> On Tue, Aug 16, 2011 at 3:35 PM, Elijah Zupancic  
>> wrote:
>>> Hi Simo,
>>>
>>> Yes, the patch is binary compatible with the old chain with one exception:
>>>
>>> org.apache.commons.chain.web.servlet.ServletHeaderValuesMap on line
>>> 97. Previously the API was returning Set>> Enumeration> when by all indications it actually should have
>>> been returning Set>. I believe that I fixed a
>>> previously undiscovered bug there.
>>>
>>> Right now, none of the unit tests are using generics and they all
>>> pass. So, I assume that we have a backwards compatible API.
>>>
>>> Thanks,
>>> -Elijah
>>>
>>> On Tue, Aug 16, 2011 at 2:00 AM, Simone Tripodi
>>>  wrote:
>>>> Hi Elijah,
>>>> looking at the patch, it seems that v2.0 is binary compatible to old
>>>> chain, right?
>>>> I mean, if in a my hypothetical application I would upgrade to v2
>>>> (generics a part) old code should continue working, right?
>>>> TIA, and count also on me!
>>>> All the best, have a nice day!
>>>> Simo
>>>>
>>>> http://people.apache.org/~simonetripodi/
>>>> http://www.99soft.org/
>>>>
>>>>
>>>>
>>>> On Mon, Aug 15, 2011 at 6:50 PM, Elijah Zupancic  
>>>> wrote:
>>>>> Hi Matt,
>>>>>
>>>>> Thanks for the advice. I've created a JIRA issue for the patch
>>>>> (https://issues.apache.org/jira/browse/CHAIN-53) and signed and
>>>>> submitted the CLA.
>>>>>
>>>>> As for JSF, I believe I made a mistake in changing the API to use the
>>>>> office jsf API instead of the myfaces API that was previously being
>>>>> used. I went that route because I couldn't find a 2.0 version of the
>>>>> faces api in the Maven repo, but it looks like it is available on the
>>>>> myfaces project site, so I will revert the dependency to using myfaces
>>>>> and downgrade to 2.0.
>>>>>
>>>>> I'll start work on migrating the test cases / mocking to a newer junit
>>>>> and mockito, when I know that the changes will be accepted.
>>>>>
>>>>> Thanks again for the help!
>>>>>
>>>>> -Elijah
>>>>>
>>>>> On Mon, Aug 15, 2011 at 6:22 AM, Matt Benson  wrote:
>>>>>> Hi, Elijah--
>>>>>>
>>>>>>  I am neither a develop nor even a user of chain, so my comments will
>>>>>> be high-level.  Firstly, by all means upgrade to whatever JUnit 4
>>>>>> release version you like, e.g. 4.8.2.  Next, I personally am a big fan
>>>>>> of Mockito, so no complaints here on that account.  I can't guarantee
>>>>>> noone else would complain, but [chain] has been fairly unloved for a
>>>>>> good while.  As for JSF 2.1, is there something this achieves that
>>>>>> wouldn't be equally well accomplished by simply upgrading to 2.0?
>>>>>> This would give [chain]'s JSF support (which I personally hadn't
>>>>>> realized existed) a potentially better combination of
>>>>>> doing-things-that-couldn't-easily-be-done-with-older-APIs vs. broadest
>>>>>> possible applicability.
>>>>>>
>>>>>> Finally, as you don't seem to be a committer your final submission in
>>>>>> this regard would be best recommended in the form of a JIRA issue, and
>>>>>> your patches in (albeit large) patch form.  In addition to this, the
>>>>>> scope of these changes indicates it best IMO that you submit an
>>>>>> Individual Contributor License Agreement governing your contributions
>>>>>> to the ASF.  See http://www.apache.org/licenses/#clas for details on
>>>>>> how to do this.
>>>>>>
>>>&g

Re: [chain][discuss] v2 upgrade

[Paul Benedict]

Any thoughts on dumping the checked exception?
public interface Command { ... boolean execute(T
context) throws Exception; }

Paul

On Mon, Aug 22, 2011 at 9:46 AM, Matt Benson  wrote:
> I am generally in favor.  I think it could be good to apply his patch
> on a branch so we can discuss the clirr results and agree on the
> severity of the (IMHO forgivable) backward-compatibility breaches.
> Then we will understand the proper path forward with respect to
> versions and all the changes that cascade from the potential major
> version bump.
>
> Matt
>
> On Mon, Aug 22, 2011 at 1:03 AM, Simone Tripodi
>  wrote:
>> Hi all guys,
>> Elijah, a [chain] user, has been submitting worthy contributions[1] to
>> improve and actualize the commons-chains component, providing also
>> patches[2].
>> I think it is the good time to start speaking about the next [chain]
>> version (no new releases/development in the last months), any
>> objections on applying Elijah patch?
>> I can take care of it but please let me know if anyone else want to do.
>> Many thanks in advance, have a nice day!!!
>> Simo
>>
>> [1] http://markmail.org/message/ajh3sunrst7x5klv
>> [2] https://issues.apache.org/jira/browse/CHAIN-53
>>
>> 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
>>
>>
>
> -
> 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: [chain][discuss] v2 upgrade - follow-up

[Paul Benedict]

I am curious about the change of normal collections to concurrent
collections. Is there overhead with the concurrent stuff? Most of my
context access is not multithreaded.

On Mon, Aug 29, 2011 at 2:53 PM, Simone Tripodi
 wrote:
> Hi all guys,
> I just fixed the clirr report generation and deployed the chain2 site
> on my personal ASF space[1], in order we can discuss the patch that
> Elijah kindly provided.
> WDYT? It is IMHO acceptable in order to apply the modifications in /trunk.
> TIA, all the best!!!
> Simo
>
> [1] http://people.apache.org/~simonetripodi/chain/clirr-report.html
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Tue, Aug 23, 2011 at 10:52 AM, Simone Tripodi
>  wrote:
>> Hi Matt,
>> your suggestion makes indeed a lot of sense! I'll copy the /trunk to a
>> branch and publish the site, once applied the patch, on my home@asf as
>> soon as I have spare time today, so we can discuss together clirr
>> report results.
>> Many thanks for your hint, have a nice day!!!
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Mon, Aug 22, 2011 at 4:46 PM, Matt Benson  wrote:
>>> I am generally in favor.  I think it could be good to apply his patch
>>> on a branch so we can discuss the clirr results and agree on the
>>> severity of the (IMHO forgivable) backward-compatibility breaches.
>>> Then we will understand the proper path forward with respect to
>>> versions and all the changes that cascade from the potential major
>>> version bump.
>>>
>>> Matt
>>>
>>> On Mon, Aug 22, 2011 at 1:03 AM, Simone Tripodi
>>>  wrote:
 Hi all guys,
 Elijah, a [chain] user, has been submitting worthy contributions[1] to
 improve and actualize the commons-chains component, providing also
 patches[2].
 I think it is the good time to start speaking about the next [chain]
 version (no new releases/development in the last months), any
 objections on applying Elijah patch?
 I can take care of it but please let me know if anyone else want to do.
 Many thanks in advance, have a nice day!!!
 Simo

 [1] http://markmail.org/message/ajh3sunrst7x5klv
 [2] https://issues.apache.org/jira/browse/CHAIN-53

 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


>>>
>>> -
>>> 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: [chain][discuss] v2 upgrade - follow-up

[Paul Benedict]

On Wed, Aug 31, 2011 at 9:45 AM, Simone Tripodi
 wrote:
> Hi all guys,
> I noticed that properly setting the 1.5 as target compliance level,
> there are some @Override annotations that in cases of interfaces
> methods implementation should be dropped. Do you agree on it?

Yes, @Override from interfaces is supported only in 1.6
>
> Moreover, I'd like to propose to split the chain component, for v2.0,
> in a multi-module project:
>
> - core APIs;
> - XML configuration APIs (depends from Digester);
> - servlet (depends from Servlet APIs);
> - portlet (depends from Portlet APIs);
> - faces (depends from Faces APIs).
>
> in that way users interested on core APIs only don't need to bring
> unused code; that looks to me a cleaner common approach used in
> various projects inside the ASF (cocoon3, for example) and outside
> (i.e. slf4j). What's your opinion about it?
>

Totally agree. Picking through optional dependencies can be difficult.
Though I would like to see the Chain API 2.0 javadoc aggregate all
those sub-projects together. I don't think it helps the user if we
break things down but can't get the documentation to show the full
picture.

Paul

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

Re: [chain][discuss] v2 upgrade - follow-up

[Paul Benedict]

On Wed, Aug 31, 2011 at 12:02 PM, Simone Tripodi
 wrote:
> Hi Paul,
> if I remember correctly, maven should be able to aggregate submodules
> apidocs, I will ask to mvn ML.

Yes, it can. The javadoc plugin has an aggregate option.

Paul

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

Re: [chain][discuss] v2 upgrade - follow-up

[Paul Benedict]

> At the same time, everybody: do you agree on replacing package.html
> with package-info.java?

+1

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

Re: [chain][discuss] v2 upgrade - follow-up

[Paul Benedict]

Well... I follow this pattern:
http://apr.apache.org/versioning.html


On Wed, Aug 31, 2011 at 2:12 PM, Simone Tripodi
 wrote:
> thanks!!!
> what about dropping deprecated methods? since we are upgrading to
> major version, they can be dropped... or not?
> TIA!!!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Wed, Aug 31, 2011 at 9:08 PM, Paul Benedict  wrote:
>>> At the same time, everybody: do you agree on replacing package.html
>>> with package-info.java?
>>
>> +1
>>
>> -
>> 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: [chain][v2] clever context

[Paul Benedict]

I want to get rid of it extending map. Have it define as asMap()
function instead. Especially since JDK 8 is bringing in extension
methods, which adds new (and default) methods to all collections, it
won't look very nice. Let's make a break now.

On Sun, Sep 4, 2011 at 9:20 PM, Raman Gupta  wrote:
> On 09/04/2011 04:00 PM, James Carman wrote:
>> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi  
>> wrote:
>>>
>>> That is able to 'auto-cast' the retrieved object while Map#get() not.
>>>
>>
>> I believe the feature is actually called "type inference", not "auto-cast."  
>> :)
>
> Thanks for the explanation... I see now that via the generic method
> the compiler infers the return type from the assignment type.
>
> Cheers,
> Raman
>
> -
> 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: [chain][v2] clever context

[Paul Benedict]

Major versions don't need to keep compatibility. Even if it is
laudable goal to try, I rather have a better designed software and do
30 minutes of upgrading code than keep dragging along old decisions.

On Mon, Sep 5, 2011 at 10:49 AM, Raman Gupta  wrote:
> On 09/05/2011 08:51 AM, Simone Tripodi wrote:
>> I totally agree with you James, what is needed is just to understand
>> if break the 1.X compatibility or not...
>> I think that the discussion worths a vote call at that point, WDYT?
>> Many thanks in advance, have a nice day!
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>
> As a chain user, I'd be fine with that for 2.x: +1 non-binding.
>
> Cheers,
> Raman
>
> -
> 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] Running lang under a security manager and LANG-744

[Paul Benedict]

Make the sun class be loaded dynamically -- not statically -- and if
it is not present, just throw an UnsupportedOperationException? I
think that would solve Android's problem.

On Tue, Sep 6, 2011 at 8:36 AM, sebb  wrote:
> On 6 September 2011 05:44, David Karlsen  wrote:
>> I think tying to sun classes is a bad idea.
>
> Yes, which is why the code checks to see if the class is present.
>
> If the Java 6 method is available, then it uses that, otherwise it
> checks for the Sun method.
> If neither is available, then the code throws an
> UnsupportedOperationException in the stripAccents() method.
>
>> Den 6. sep. 2011 05:54 skrev "sebb"  følgende:
>>> On 6 September 2011 04:33, Henri Yandell  wrote:
 On Sat, Sep 3, 2011 at 8:10 AM, sebb  wrote:
> On 3 September 2011 05:37, Henri Yandell  wrote:
>> I'm less concerned with the 115 errors, unless they're all as grievous
>> as the StringUtils one - ie) the method causing trouble is not the
>> only one broken.
>>
>> If the error happened when calling stripAccents, that would be
>> workable; but having all of StringUtils unavailable is very painful.
>> One option would be to move the code out of the static initializer and
>> make it lazy when stripAccents is first called - leading to only
>> callers of stripAccents when the JDK 6 class is unavailable to suffer
>> pain.
>
> I thought we'd already fixed that by catching the extra Exception?
>
> I already suggested localising the error display to the stripAccents
>> method.

 Sorry - not operating at 100% last week.

>> I thought we could simplify things by simply making the java6Available
>> flag be a real test for Java 6, but Android seems very weird there. Is
>> Android going to force us to stay on the EOL Java 5, or is it Java 6
>> compatible? IIUC it reports itself as 0.9, which we've declared as
>> equivalent to JDK 1.5.
>
> Are you sure that is the issue?
> Surely the Android problem is that we check for the sun class but
> don't handle all possible errors?
> So the class does not load; it cannot use the Java6 method even if it
>> exists.

 I'm very confused between Android and GAE :)

>> That relates to another (simple) solution - move to Java 6 :)
>
> Or capture Exception for both the java6 and sun tests; report the
> exception(s) if neither is available when required.

 I like this. Capture the exception in the static initializer and then
 throw a new runtime exception in stripAccents that refers to said
 exception. Perhaps an IllegalStateException("blah", originalException)
 ?
>>>
>>> It currently throws UnsupportedOperationException; I think we should
>>> keep that as it's more accurate.
>>>
>>> There will always be two Exceptions at that point (otherwise we must
>>> have Java 6 or Sun).
>>> We know we need to report the Sun Exception - is there any need to
>>> report the Java 6 exception?
>>> i.e. could we be running on Java 6 but still get an Exception?
>>>
>>> For completeness (and debugging) we should probably report both.
>>>
>>> Perhaps we could nest the exceptions.
>>>
 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
>
>

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

Re: [RESULT][CHAIN][VOTE] accept the 2.0-work brach as proper codebase in /trunk

[Paul Benedict]

Here's my +1 non-binding.

On Thu, Sep 8, 2011 at 1:38 PM, Simone Tripodi  wrote:
> Hi all,
> The proposal of making the 2.0-work brach as proper codebase in /trunk
> for the [chain] component passes with 3 +1 binding votes from
>
>  * Simone Tripodi
>  * James Carman
>  * Matt Benson
>
> no other votes have been casted.
>
> I'm going to move the current trunk in a 1.X branch, and the 2.0-work in 
> trunk.
> Thanks for participating, all the best!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Wed, Sep 7, 2011 at 4:24 PM, Matt Benson  wrote:
>> On Mon, Sep 5, 2011 at 10:13 AM, Simone Tripodi
>>  wrote:
>>> Hi all guys,
>>> thanks to a user, Elijah Zupancic, that recently submitted CHAIN-53, a
>>> group of Commons committers started working on that component in a
>>> branch 2.0[1] to experiment updates and study improvements in order to
>>> push a next release soon.
>>> We are in the middle of discussing about the current/improved design,
>>> maintaining - or not - the retro-compatibility, better modularization
>>> - splitting the chain in submodules - and so on, so as you maybe
>>> noticed latest ML activity looks like there is a renewed interest from
>>> both committers and users that came back to submit contributions.
>>> You would be maybe interested on see which level of
>>> retro-compatibility we maintained after the update, by reading the
>>> Clirr report[2] published on my personal ASF space.
>>> So we are interested on releasing that code and our proposal is to
>>> move the current trunk in a 1.x branch and move the 2.0 work in trunk,
>>> please cast your vote:
>>>
>>> [+1]    let's make the branch the code we want to see released as new chain
>>> [+/- 0] feel free to express opinions
>>> [-1]     because...
>>
>> +1
>>
>> Matt
>>
>>>
>>> Feedbacks are, obviously, welcome.
>>> Many thanks in advance, all the best!!!
>>> Simo
>>>
>>> [1] 
>>> https://svn.apache.org/repos/asf/commons/proper/chain/branches/version-2.0-work
>>> [2] http://people.apache.org/~simonetripodi/chain/clirr-report.html
>>>
>>> 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
>>>
>>>
>>
>> -
>> 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: [chain][v2] clever context

[Paul Benedict]

On Fri, Sep 9, 2011 at 1:47 PM, Elijah Zupancic  wrote:
> Thanks for your comments Nail.
>
> I think that I've come around to see your point after sleeping on it.
> What do you think about this:
>
> Context.java - would be defined as so:
>
> public interface Context extends Map

Isn't that identical to?
public interface Context extends Map

> Then ContextBase.java would be defined like so:
>
> public class ContextBase extends ConcurrentHashMap
>                implements Context {

Paul

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

Re: [chain][v2] clever context

[Paul Benedict]

I go with what I said. Extending from Object is sulfurous since all
type parameters extend at least from Object.

On Fri, Sep 9, 2011 at 1:56 PM, Elijah Zupancic  wrote:
> Paul,
>
> You may be right. Which one is more idiomatic?
>
> Thanks,
> -Elijah
>
> On Fri, Sep 9, 2011 at 11:51 AM, Paul Benedict  wrote:
>> On Fri, Sep 9, 2011 at 1:47 PM, Elijah Zupancic  wrote:
>>> Thanks for your comments Nail.
>>>
>>> I think that I've come around to see your point after sleeping on it.
>>> What do you think about this:
>>>
>>> Context.java - would be defined as so:
>>>
>>> public interface Context extends Map>> V>
>>
>> Isn't that identical to?
>> public interface Context extends Map
>>
>>> Then ContextBase.java would be defined like so:
>>>
>>> public class ContextBase extends ConcurrentHashMap
>>>                implements Context {
>>
>> Paul
>>
>> -
>> 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: [chain][v2] clever context

[Paul Benedict]

In my personal use of Chain, I am using it as . So
typing as Context is good. Though, do we need type T? Shouldn't
retrieve(K) just return V?

On Fri, Sep 9, 2011 at 2:21 PM, Simone Tripodi  wrote:
> here I am!
> sorry I'm late but just terminated to have dinner :P
> I think that specifying the  can be omitted, and
> Paul's suggestion is the way to go, the code is more readable.
>
> The last added method can be improved, putting the K as argument
> instead of String and  as a strict check for output
> argument:
>
> public interface Context
>    extends Map
> {
>
>     T retrieve(K key);
>
> }
>
> what I think is not so nice to have, is the Command, Filter, Chain,
> ..., notation that, getting Context as argument in their methods,
> would require generics...
>
> Lets' think about it, thanks for sharing your thoughts!!!
> All the best,
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Fri, Sep 9, 2011 at 8:56 PM, Elijah Zupancic  wrote:
>> Paul,
>>
>> You may be right. Which one is more idiomatic?
>>
>> Thanks,
>> -Elijah
>>
>> On Fri, Sep 9, 2011 at 11:51 AM, Paul Benedict  wrote:
>>> On Fri, Sep 9, 2011 at 1:47 PM, Elijah Zupancic  
>>> wrote:
>>>> Thanks for your comments Nail.
>>>>
>>>> I think that I've come around to see your point after sleeping on it.
>>>> What do you think about this:
>>>>
>>>> Context.java - would be defined as so:
>>>>
>>>> public interface Context extends 
>>>> Map
>>>
>>> Isn't that identical to?
>>> public interface Context extends Map
>>>
>>>> Then ContextBase.java would be defined like so:
>>>>
>>>> public class ContextBase extends ConcurrentHashMap
>>>>                implements Context {
>>>
>>> Paul
>>>
>>> -
>>> 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: [chain][v2] clever context

[Paul Benedict]

On Fri, Sep 9, 2011 at 3:06 PM, Simone Tripodi  wrote:
> Hi Paul,
> the use of that method is to automatically infer the assigned type,
> instead of writing
>
>    MyPojo myPojo = (MyPojo) context.get( "myKey" );
>
> the retrieve method allows to
>
>    MyPojo myPojo = context.retrieve( "myKey" );
>

Hmm... The inference should be automatic unless you specified Object for type V:
Context properties = new ContextBase();
String value = properties.retrieve("myKey");

Paul

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

Re: [chain][v2] clever context

[Paul Benedict]

On Fri, Sep 9, 2011 at 3:15 PM, Elijah Zupancic  wrote:
> Specifying Object for V would be the most likely use case.
>
> On Fri, Sep 9, 2011 at 1:12 PM, Paul Benedict  wrote:
>> On Fri, Sep 9, 2011 at 3:06 PM, Simone Tripodi  
>> wrote:
>>> Hi Paul,
>>> the use of that method is to automatically infer the assigned type,
>>> instead of writing
>>>
>>>    MyPojo myPojo = (MyPojo) context.get( "myKey" );
>>>
>>> the retrieve method allows to
>>>
>>>    MyPojo myPojo = context.retrieve( "myKey" );
>>>
>>
>> Hmm... The inference should be automatic unless you specified Object for 
>> type V:
>> Context properties = new ContextBase();
>> String value = properties.retrieve("myKey");
>>

I don't have a good answer for the problem. I just think if you
declare types  at the class level, those should be the types
used on the methods too. The problem that I have with  is
that it assumes a type-safe cast. You are right to say
ClassCastException was thrown for both of your examples but  breaks the "rule" that generics should be type-safe casts. It's
better to have the user create a bum cast and fail then the compiler
infer a bum cast and fail, imo.

Paul

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

Re: [chain][v2] clever context

[Paul Benedict]

The purpose of Generics is to provide type safety with the implicit
casts. Implicit casts because of typing shouldn't cause a
ClassCastException. That would break an important principle behind
using gnerics. Are you sure Guava is doing what you're proposing?
Typing should always be safe; I would be surprised if they would allow
unsafe implicit casts.

On Fri, Sep 9, 2011 at 3:34 PM, Simone Tripodi  wrote:
> Hi Paul,
> the type inference becomes more interesting and useful if you think to
> more complicated context instances, take as sample the Guava's
> ClassToInstanceMap[1] where values extend a specific base type.
>
> the   in the `retrieve` method reduces anyway the number
> of errors, given an hypothetically  Context users
> cannot cast to a different type:
>
> MyPojo myPojo = (MyPojo) context.get( "myKey" );
>
> I think anyway putting types to Context would make Filter, Command,
> Chain, ... classes over engineered IMHO
>
> best,
> Simo
>
> [1] http://s.apache.org/xfj
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Fri, Sep 9, 2011 at 10:20 PM, Paul Benedict  wrote:
>> On Fri, Sep 9, 2011 at 3:15 PM, Elijah Zupancic  wrote:
>>> Specifying Object for V would be the most likely use case.
>>>
>>> On Fri, Sep 9, 2011 at 1:12 PM, Paul Benedict  wrote:
>>>> On Fri, Sep 9, 2011 at 3:06 PM, Simone Tripodi  
>>>> wrote:
>>>>> Hi Paul,
>>>>> the use of that method is to automatically infer the assigned type,
>>>>> instead of writing
>>>>>
>>>>>    MyPojo myPojo = (MyPojo) context.get( "myKey" );
>>>>>
>>>>> the retrieve method allows to
>>>>>
>>>>>    MyPojo myPojo = context.retrieve( "myKey" );
>>>>>
>>>>
>>>> Hmm... The inference should be automatic unless you specified Object for 
>>>> type V:
>>>> Context properties = new ContextBase();
>>>> String value = properties.retrieve("myKey");
>>>>
>>
>> I don't have a good answer for the problem. I just think if you
>> declare types  at the class level, those should be the types
>> used on the methods too. The problem that I have with  is
>> that it assumes a type-safe cast. You are right to say
>> ClassCastException was thrown for both of your examples but > V> breaks the "rule" that generics should be type-safe casts. It's
>> better to have the user create a bum cast and fail then the compiler
>> infer a bum cast and fail, imo.
>>
>> Paul
>>
>> -
>> 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: [chain][v2] clever context

[Paul Benedict]

Definitely interesting. I think this might be a special case though;
ClassToInstanceMap is dedicated to class instances which is probably
why they extended Map so that it has extra guarantees. I don't know if
such a pattern is advisable for a regular key/value pair. What are
your thoughts?

On Fri, Sep 9, 2011 at 4:14 PM, Simone Tripodi  wrote:
> indeed, the retrieve method would allow users assigning retrieved
> object to all T that extend V, like the ClassToInstanceMap, take a
> look at the method signatures[1]
>
> [1] http://s.apache.org/Mno
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Fri, Sep 9, 2011 at 11:02 PM, Paul Benedict  wrote:
>> The purpose of Generics is to provide type safety with the implicit
>> casts. Implicit casts because of typing shouldn't cause a
>> ClassCastException. That would break an important principle behind
>> using gnerics. Are you sure Guava is doing what you're proposing?
>> Typing should always be safe; I would be surprised if they would allow
>> unsafe implicit casts.
>>
>> On Fri, Sep 9, 2011 at 3:34 PM, Simone Tripodi  
>> wrote:
>>> Hi Paul,
>>> the type inference becomes more interesting and useful if you think to
>>> more complicated context instances, take as sample the Guava's
>>> ClassToInstanceMap[1] where values extend a specific base type.
>>>
>>> the   in the `retrieve` method reduces anyway the number
>>> of errors, given an hypothetically  Context users
>>> cannot cast to a different type:
>>>
>>> MyPojo myPojo = (MyPojo) context.get( "myKey" );
>>>
>>> I think anyway putting types to Context would make Filter, Command,
>>> Chain, ... classes over engineered IMHO
>>>
>>> best,
>>> Simo
>>>
>>> [1] http://s.apache.org/xfj
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Fri, Sep 9, 2011 at 10:20 PM, Paul Benedict  wrote:
>>>> On Fri, Sep 9, 2011 at 3:15 PM, Elijah Zupancic  
>>>> wrote:
>>>>> Specifying Object for V would be the most likely use case.
>>>>>
>>>>> On Fri, Sep 9, 2011 at 1:12 PM, Paul Benedict  
>>>>> wrote:
>>>>>> On Fri, Sep 9, 2011 at 3:06 PM, Simone Tripodi 
>>>>>>  wrote:
>>>>>>> Hi Paul,
>>>>>>> the use of that method is to automatically infer the assigned type,
>>>>>>> instead of writing
>>>>>>>
>>>>>>>    MyPojo myPojo = (MyPojo) context.get( "myKey" );
>>>>>>>
>>>>>>> the retrieve method allows to
>>>>>>>
>>>>>>>    MyPojo myPojo = context.retrieve( "myKey" );
>>>>>>>
>>>>>>
>>>>>> Hmm... The inference should be automatic unless you specified Object for 
>>>>>> type V:
>>>>>> Context properties = new ContextBase();
>>>>>> String value = properties.retrieve("myKey");
>>>>>>
>>>>
>>>> I don't have a good answer for the problem. I just think if you
>>>> declare types  at the class level, those should be the types
>>>> used on the methods too. The problem that I have with  is
>>>> that it assumes a type-safe cast. You are right to say
>>>> ClassCastException was thrown for both of your examples but >>> V> breaks the "rule" that generics should be type-safe casts. It's
>>>> better to have the user create a bum cast and fail then the compiler
>>>> infer a bum cast and fail, imo.
>>>>
>>>> Paul
>>>>
>>>> -
>>>> 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: [chain][v2] clever context - follow-up

[Paul Benedict]

The basic context should be Context and then use interface
composition to define other things like:

public interface PropertyContext extends Context,
Map

It can be done... I think :-)

Paul

On Fri, Sep 16, 2011 at 3:40 PM, Simone Tripodi
 wrote:
> Hi Elijah,
> I spent some spare time trying to figure out how to improve the
> Context design, I didn't have a lot of success anyway :(
>
>  * dropping the Map inheritance makes not easy maintaining the classes
> in the 'generic' package;
>  * adding generics in the Context to specify K,V types, makes all the
> rest of the notation not so nice (IMHO), take a look as a sample a
> Command> :?
>
> Do you have more ideas?
> Many thanks in advance, all the best!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Wed, Sep 14, 2011 at 4:12 AM, Elijah Zupancic  wrote:
>> Hi Everyone,
>>
>> I don't have any votes as I'm not a commiter, but I would still like to add
>> in my suggestion.
>>
>> After our previous exchange, I'm of the mind that we should use the second
>> option - that is be collection agnostic and work by composition. I may be
>> biased towards defined getters and setters, but I really like to be able to
>> use auto-complete, automatic code refactoring tools and static code analysis
>> tools. If we used only a Map, then the contract for a context becomes a
>> black box of anything. I like the way it is now where you have to implement
>> a Map on your context or extend ContextBase. I may be biased out of habit -
>> if so, please convince me (by proxy everyone else).
>>
>> Thanks,
>> -Elijah
>>
>> On Mon, Sep 12, 2011 at 12:04 AM, Simone Tripodi
>> wrote:
>>
>>> Hi all guys,
>>> after mails and mails of discussions, I don't think there is a general
>>> agreement on how Context API should look alike.
>>> At the end of the discussions I figured out that, briefly resuming, we
>>> have following proposals:
>>>
>>>  * be replaced by Map;
>>>  * be Collection agnostic and work by composition.
>>>
>>> Please add what is missing and correct what is wrong; we need to find
>>> a general agreement before to continue working toward the 2.0 release
>>> :)
>>>
>>> TIA, all the best!!!
>>> Simo
>>>
>>> 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
>>>
>>>
>>
>
> -
> 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: [chain][v2] clever context - follow-up

[Paul Benedict]

Should the context in the command be parametrized? I don't think
that's such a good idea. Isn't one of the benefits of Chain is that
you don't know which context you might be getting?

Paul

On Mon, Sep 19, 2011 at 10:12 AM, Simone Tripodi
 wrote:
> Hi Elijah,
> I had e deeper look at your patch and raw more carefully your message,
> I just have a BIG trouble: when changing the Context interface to
>
> public interface Context extends Map {
>
> }
>
> you can easily note that, in Command interface (just to mention one)
> compiler complains:
>
>    "Context is a raw type. References to generic type Context
> should be parametrized"
>
> and we can not just ignore it... that's why I thought that adopting
> the signature Command> in the command
> interface is not nice but needed.
> More thoughts?
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Mon, Sep 19, 2011 at 10:01 AM, Simone Tripodi
>  wrote:
>> Hi Elijah!
>> great report, thanks for your effort! :)
>> I'll have a look at your patch as soon as I get a spare time slot,
>> I'll let you know ASAP!
>> Have a nice day, all the best!
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Mon, Sep 19, 2011 at 3:52 AM, Elijah Zupancic  
>> wrote:
>>> I just submitted a patch to jira as CHAIN-58. This changes Context to
>>> Context.
>>>
>>> Thanks,
>>> -Elijah
>>>
>>> On Fri, Sep 16, 2011 at 2:16 PM, Simone Tripodi 
>>> wrote:
>>>
>>>> Hi Paul!
>>>> yes it can be done, of course :) I'm not convinced anyway by the heavy
>>>> notation that, modifying the Context, would impact the Command and
>>>> Filter classes. I think it is because just a matter of taste :P
>>>> Feedbacks/suggestions/patches are welcome, if you want to provide a
>>>> solution feel free to fill an issue and attach a patch!!
>>>> TIA, all the best!
>>>> Simo
>>>>
>>>> http://people.apache.org/~simonetripodi/
>>>> http://www.99soft.org/
>>>>
>>>>
>>>>
>>>> On Fri, Sep 16, 2011 at 11:05 PM, Paul Benedict 
>>>> wrote:
>>>> > The basic context should be Context and then use interface
>>>> > composition to define other things like:
>>>> >
>>>> > public interface PropertyContext extends Context,
>>>> > Map
>>>> >
>>>> > It can be done... I think :-)
>>>> >
>>>> > Paul
>>>> >
>>>> > On Fri, Sep 16, 2011 at 3:40 PM, Simone Tripodi
>>>> >  wrote:
>>>> >> Hi Elijah,
>>>> >> I spent some spare time trying to figure out how to improve the
>>>> >> Context design, I didn't have a lot of success anyway :(
>>>> >>
>>>> >>  * dropping the Map inheritance makes not easy maintaining the classes
>>>> >> in the 'generic' package;
>>>> >>  * adding generics in the Context to specify K,V types, makes all the
>>>> >> rest of the notation not so nice (IMHO), take a look as a sample a
>>>> >> Command> :?
>>>> >>
>>>> >> Do you have more ideas?
>>>> >> Many thanks in advance, all the best!
>>>> >> Simo
>>>> >>
>>>> >> http://people.apache.org/~simonetripodi/
>>>> >> http://www.99soft.org/
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Wed, Sep 14, 2011 at 4:12 AM, Elijah Zupancic 
>>>> wrote:
>>>> >>> Hi Everyone,
>>>> >>>
>>>> >>> I don't have any votes as I'm not a commiter, but I would still like to
>>>> add
>>>> >>> in my suggestion.
>>>> >>>
>>>> >>> After our previous exchange, I'm of the mind that we should use the
>>>> second
>>>> >>> option - that is be collection agnostic and work by composition. I may
>>>> be
>>>> >>> biased towards defined getters and setters, but I really like to be
>>>> able to
>>>> >>> use auto-complete, automatic code refactoring tools and static code
>>>> analysis
>>>> >>> tools. If we used only a 

Re: [pool] should addObject return a boolean?

[Paul Benedict]

I think a boolean is a good indicator for whether the operation was
honored or not.

Paul

On Tue, Sep 20, 2011 at 11:41 PM, Gary Gregory  wrote:
> On Wed, Sep 21, 2011 at 12:09 AM, Phil Steitz  wrote:
>
>> On 9/20/11 8:24 PM, Gary Gregory wrote:
>> > That sounds reasonable.
>> >
>> > Would any call sites prefer an exception. Checked or unchecked?
>>
>> I suppose in some cases some clients / pool implementations might
>> want to throw IllegalStateException if an attempt is made to add to
>> a pool at capacity, but there are others (including internal to GOP,
>> GKOP) where it is more convenient for it to be a no-op.  Checking a
>> boolean return or just allowing the no-op is lighter weight than
>> catching an exception, so the boolean return is probably better.
>> Implementations that want to throw can document and throw unchecked
>> exceptions (e.g. ISE) and clients can also throw on the false return
>> if they want.
>>
>
> Well, it sounds like the KISS solution is the boolean. I'd say go for that
> until something better is needed.
>
> Gary
>
>
>> Phil
>> >
>> > Gary
>> >
>> > On Tue, Sep 20, 2011 at 10:53 PM, Phil Steitz 
>> wrote:
>> >
>> >> When GKOP or GOP pools lack capacity, addObject does nothing.  In
>> >> some cases (I am dealing with one now internally to GKOP), it would
>> >> be good to know if an instance was actually added or not.  How about
>> >> changing the interface (both OP and KOP versions) to return a
>> >> boolean with true indicating that a new instance was actually
>> >> created and added to the pool?
>> >>
>> >> 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
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: 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: [VOTE] Release Apache Commons Gigester 3.2 based on RC2

[Paul Benedict]

Any product called the Gigester gets my +1 vote!

On Sun, Dec 11, 2011 at 10:56 AM, Oliver Heger  wrote:

> +1
>
> Build works fine with Java 1.5 on Windows 7. Artifacts and site look good.
>
> One minor nit: In the release notes the following recommended dependencies
> are listed:
> "The Recommended Dependency Set for Digester 3.0 is:
>   Digester 3.1 + Logging 1.1.1 + BeanUtils 1.8.3"
>
> This is a bit confusing due to the different Digester version numbers.
> Also, the site lists CGLib as additional dependency.
>
> Oliver
>
> Am 10.12.2011 16:18, schrieb Simone Tripodi:
>
>  Hi all guys,I'm writing to call for a vote to release apache
>> commons-digester-3.2 based on RC2.
>> Please take in consideration that: * broken 3.2 links will be fixed
>> once the site will be deployed; * there is a Clirr violation, but:
>> 1) target class is used for internal use only - there is no way users
>> can reuse it;   2) arguments type are still assignable.
>> The vote will stay open for at least 72 hours and closes approximately
>> on Tuesday 13th, at 3:20pm CET.
>> Many thanks in advance for reviewing, have a nice day!All the best,-Simo
>> Release notes:
>>  http://people.apache.org/**builds/commons/digester/3.2/**
>> RC2/RELEASE-NOTES.txt
>> Tag:
>>  https://svn.apache.org/repos/**asf/commons/proper/digester/**
>> tags/DIGESTER3_3_2_RC2/
>> Site:
>>  
>> http://people.apache.org/**builds/commons/digester/3.2/**RC2/site/
>> Binaries:
>>  
>> http://people.apache.org/**builds/commons/digester/3.2/**RC2/binaries/
>> Maven Artifacts (staged on Nexus)
>>  https://repository.apache.org/**content/repositories/**
>> orgapachecommons-310/org/**apache/commons/commons-**digester3/3.2/
>> [ ] +1 release it[ ] +0 go ahead I don't care[ ] -1 no, do not release
>> it because... (please explain why)
>>
>> http://people.apache.org/~**simonetripodi/
>> http://simonetripodi.**livejournal.com/
>> http://twitter.com/**simonetripodi 
>> http://www.99soft.org/
>>
>> --**--**-
>> To unsubscribe, e-mail: 
>> dev-unsubscribe@commons.**apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@commons.**apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [ALL][VOTE] Rename Commons Sanselan to Commons Image

[Paul Benedict]

-0
I think project names are ASF property (like a trademark). Without
clarification from the board or legal, the vote seems premature.
On Dec 22, 2011 5:32 AM, "Mark Thomas"  wrote:

> On 19/12/2011 14:54, Gary Gregory wrote:
> > This is a VOTE to [ALL] to rename Commons Sanselan to Commons Image.
> >
> > The drive is to have a meaningful obvious name like [Lang], [IO], [Net],
> > and so on.
> >
> > This VOTE is open until December 22, 10AM EST.
>
> -1.
>
> The naming decision was made by the community when Sanselan joined
> Commons 2.5 years ago [1] and I see no reason to revisit that decision.
> I am rather disappointed to see this being rehashed after the issue has
> already been resolved.
>
> Not all Commons components have functional names. If the Sanselan
> community wants to use that name then I have no problem with that.
>
> Mark
>
> [1] http://markmail.org/thread/zn4y4ah2x4crgsow
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[beans] Documentation unavailable

[Paul Benedict]

FYI, the website no longer hosts the API and user guide. The links are
broken.

Paul

[beans] Documentation links are broken

[Paul Benedict]

FYI, the site points to non-existent API and user guide. The links are
broken on both the LHS navigation and the main content.

Paul

Re: [beansutils] Documentation links are broken

[Paul Benedict]

yes :-)


On Tue, Apr 23, 2013 at 4:58 PM, sebb  wrote:

> On 23 April 2013 22:53, Paul Benedict  wrote:
>
> > FYI, the site points to non-existent API and user guide. The links are
> > broken on both the LHS navigation and the main content.
> >
> >
> Beans does not exist. I assume you meant Beanutils?
>
>
> > Paul
> >
>

Re: [DOC] Do we track infra tickets in changes.xml?

[Paul Benedict]

I always thought changes.xml was to describe the release package. If the
ticket produced no artifact update, why does it need to be part of the
distribution?


On Tue, Jun 11, 2013 at 10:30 AM, Gary Gregory wrote:

> I see no harm as adding it to changes.xml, it's a doc change that we might
> as well document like any other doc or site change.
>
> Gary
>
>
> On Tue, Jun 11, 2013 at 10:08 AM, Benedikt Ritter  >wrote:
>
> > Hello,
> >
> > we had this request [1] to create a git mirror for [beanutils]. I
> created a
> > [infra] ticket and linked it to our ticket. Now infra has created the
> > mirror and closed their issue. My question is: do I track that beanutils
> > now has a git mittor via changes.xml?
> >
> > It is an information that users may be interested in. But usually
> > changes.xml just contains changes to the code and we do have the jira
> > report. So I've probably given the answer myself?
> >
> > TIA,
> > Benedikt
> >
> > [1] https://issues.apache.org/jira/browse/BEANUTILS-404
> >
> >
> > --
> > http://people.apache.org/~britter/
> > http://www.systemoutprintln.de/
> > http://twitter.com/BenediktRitter
> > http://github.com/britter
> >
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition<
> http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>

Re: [collections] Release 4.0-alpha1 to maven?

[Paul Benedict]

AFAIK, a release is a release. If you're voting on a project, a successful
vote creates an Apache artifact that needs to be published to the world.
Maven just released their 3.1.0-alpha. That release will be forever out
there, but since it's not production quality, usage will eventually
drop-off once the GA release is pushed -- but a release is a release. So
the decision to publish a Collections 4 Alpha should be done under the same
guidelines.


On Fri, Jul 5, 2013 at 12:41 PM, Phil Steitz  wrote:

>
>
> On Jul 5, 2013, at 9:52 AM, Gary Gregory  wrote:
>
> > On Fri, Jul 5, 2013 at 12:45 PM, Phil Steitz 
> wrote:
> >
> >> On 7/5/13 9:32 AM, Gary Gregory wrote:
> >>> On Fri, Jul 5, 2013 at 11:33 AM, Phil Steitz 
> >> wrote:
> >>>
>  On 7/5/13 7:59 AM, sebb wrote:
> > On 5 July 2013 15:47, Phil Steitz  wrote:
> >> On 7/5/13 4:35 AM, Gary Gregory wrote:
> >>> Over at log4j we release betas to maven central. I think we should
> do
> >>> so here too for alphas. It's just too much of a pain to use a jar
> in
> >> a
> >>> build otherwise.
> >> Do you subsequently introduce incompatible API changes with no
> >> package name change in the "stable" releases?  That's what I would
> >> worry about here.  Collections is so widely used / depended on that
> >> having API-incompatible versions with the same package name
> >> eternally in the wild would seem a bad idea to me.
> > Surely API-instability is part of the point of an Alpha release?
> >
> > Users should be aware that if *they* release anything that depends on
> > an Alpha release it may cause breakage in the futiure.
>  It would be great if we and all downstream users of whatever stuff
>  ends up shipping with a dependency on a to-be-broken API could
>  depend on that.  History suggests that you really can't count on
>  that.   The problem is that it is not just or even primarily the
>  immediate "users" who get hurt by this.  If it were just the case of
>  project A direct user of the alpha breaking, I would agree.  For
>  something like [collections], though, the problem is project A ships
>  with alpha dependency, gets consumed by B, itself consumed by C, ...
>  and some poor soul trying to use the actual release in Z get borked
>  because somewhere along the line the now-abandoned A with
>  incompatible not package-renamed classes got consumed.
> >>> This problem happens already today with normal releases of software,
> just
> >>> with behavior changes, not even API breakages.
> >>>
> >>> At least with an alpha or beta label we are explicitly warning users.
> >>>
> >>> If *you* choose to release with a dependency on an alpha or beta
> >> component,
> >>> then *you* are creating a potential problem.
> >>>
> >>> Similarly, if *you* choose to consume a project with direct
> dependencies
> >> on
> >>> an alpha or beta, that should raise a red flag, and are also possibly
> >>> creating a problem.
> >>>
> >>> The jar hell of transitive dependencies is well know and this does not
> >> make
> >>> it any better or worse.
> >>
> >> It *does* make it worse whenever you release incompatible versions
> >> of the same class.  This is why we agreed to change package names
> >> when we do that.  We have agreed to make an exception for limited
> >> distribution alphas / betas.
> >
> >
> > There is no such thing as "limited distribution" IMO, if it's accessible
> on
> > the internet, then it's open for business.
>
>
> Good point.  I probably should have said "limited advertisement" or
> something.  A beta tarball can be pushed to the mirrors and later taken
> down when the actual release is published.  It will still be available in
> the archives and likely other places, but it will not be linked on the
> website or otherwise "advertised" once the stable release is out.  If it is
> pushed to maven central, it will forever show up among the release versions
> and builds depending on it will continue to work.  If we can get the
> feedback we need without this, my HO is that we should avoid it.
>
> Phil
>
> >
> > How about putting "alpha" in the package name? That would work for major
> > releases like collection 4 which will come in a new package anyway.
> >
> > So, call the root package o.a.c.collections4.alpha1. So if you want to
> use
> > it, you have to hard wire to it and jump through a special hoop. Same
> when
> > alpha2 and beta1 come out. Then when it's the real release, it's just
> plain
> > o.a.c.collections4.
> >
> > Gary
> >
> > We should do what we can to limit
> >> dependency propagation as we get the feedback we are looking for.
> >> Keeping the artifacts off of maven central will help.  The real
> >> question is can we get the feedback we need without forever
> >> advertising these artifacts on maven central.
> >>
> >> Phil
> >>>
> >>> Gary
> >>>
> >>>
>  Phil
> > So long as we don't break the API between non-Alpha releases, I don't
> > see this a

Re: [ALL] Alpha releases - how to stop them becoming a dependency of a released product

[Paul Benedict]

Don't try to solve how to stop an alpha release from becoming integrated.
If someone does that, there's inherit risk involved. I don't see how this
is any different, per se, a beta or RC release. If you build on unstable
code, the only support advice I'd will get is: upgrade to the latest GA. :-)


On Fri, Jul 5, 2013 at 2:13 PM, sebb  wrote:

> The thread about Collections Alpha release to Maven Central got me
> thinking.
>
> So long as an Alpha release is only used for testing/local use, it
> does not matter where it is published.
>
> The problem comes if the Alpha release becomes a dependency of another
> product which is then released.
>
> So how do we stop that from happening?
>
> Documentation helps, but some people ignore documentation.
>
> Just wondering if it would be possible to incorporate some kind of
> time-limit in the library, so that it stops working after a certain
> date?
>
> I've no idea if that is feasible - and it might cause too much of an
> overhead - but perhaps worth investigating.
>
> Obviously it would have to be well documented.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VFS] Passing around password as byte[] instead

[Paul Benedict]

Because Strings hold onto their internal char[], unreferencing a String
password means it hangs around in memory until the JVM garbage collects it.
If you can ever prevent it from becoming a String, keep it as a char[] or
byte[] -- then zero it all out before the array is unreferenced.

Paul


On Mon, Jul 8, 2013 at 7:51 PM, Gary Gregory  wrote:

> On Mon, Jul 8, 2013 at 7:05 PM, Roger L. Whitcomb <
> roger.whitc...@actian.com
> > wrote:
>
> > Well, that's what .Net did with SecureString, and OpenSSL did as well.
> > There is a longer discussion here:
> > http://stackoverflow.com/questions/8881291/why-is-char-preferred-over-st
> > ring-for-passwords
> > that talks more about the pros and cons.
> >
> > The main reason I bring it up is that, even though it doesn't provide
> > *that much* extra security, providing some help at the API levels seems
> > better than doing nothing ...  It seems that, even though it provides
> > only minimal security, it is *still* considered best practice to zero
> > out password fields as soon as possible to minimize the potential
> > security risks.
> >
> > So, seeing that VFS 2.0 is not quite released yet, it seemed like a good
> > time to at least raise the question before the API is cast in stone.
> >
>
> 2.0 has been out for a long time. 2.1 is ready for a release IMO.
>
> Gary
>
>
> >
> > I'd be willing to take a crack at a patch to implement this change if
> > there was enough interest.
> >
> > Thanks,
> > ~Roger
> >
> > -Original Message-
> > From: Honton, Charles [mailto:charles_hon...@intuit.com]
> > Sent: Monday, July 08, 2013 3:53 PM
> > To: Commons Developers List
> > Subject: Re: [VFS] Passing around password as byte[] instead
> >
> > Or maybe a Password class that's tailor designed to obsfucate and zero
> > contents...
> >
> > On 7/8/13 3:23 PM, "sebb"  wrote:
> >
> > >On 8 July 2013 23:05, Roger L. Whitcomb 
> > wrote:
> > >> I had a thought that it would be more secure to pass password data
> > >> around in VFS as byte arrays instead of String objects so they could
> > >> less easily be found by memory dumpers/scanners.  This would apply
> > >> (for
> > >> instance) to GenericFileName constructor and access methods, etc.
> > >> Obviously, at some point, you have to convert to String (like in
> > >> "GenericFileName.appendCredentials"), but it seems like at least some
> >
> > >> level of obfuscation, as in storing the data as bytes might be useful
> >
> > >> to increase security.
> > >
> > >Another reason for using bytes is that the array can be zeroed out - or
> >
> > >replaced with fake password to fool hackers ;-) - once it has been
> > >used.
> > >This is not possible with immutable strings.
> > >
> > >>
> > >>
> > >> Thoughts?  Thanks.
> > >>
> > >>
> > >>
> > >> ~Roger Whitcomb
> > >>
> > >> Apache Pivot PMC Chair
> > >>
> > >
> > >-
> > >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
> >
> >
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition<
> http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
Cheers,
Paul

Re: [csv] record.get APIs for primitive types

[Paul Benedict]

None of these methods document exceptions if the conversion fails (eg, not
an integer). Also, how strict is the conversion? Can "x" represent boolean
false or is that an exception?
On Aug 1, 2013 9:00 AM, "Gary Gregory"  wrote:

> I would like to note this CSVRecord addition I am planning on:
>
> public Boolean getBoolean(String name) {
> public boolean getBooleanPrimitive(String name)
>
> The method listings are at the end of this message.
>
> What I want to note here is that these are conversion methods and that the
> record still stores the values internally as Strings. I do not want to
> Javadoc the conversion in order to give us flexibility over representation
> if we decide to change it in the future (caching or whatnot).
>
> I wanted to post here in CTR mode before I or others add APIs like
> getLong() and getLongPrimitive(). Since this is a library, I do believe we
> should end up providing such APIs at the record level for primitives.
>
> /**
>  * Returns a value by name.
>  *
>  * @param name
>  *the name of the column to be retrieved.
>  * @return the column value, or {@code null} if the column name is not
> found
>  * @throws IllegalStateException
>  * if no header mapping was provided
>  * @throws IllegalArgumentException
>  * if the record is inconsistent
>  * @see #isConsistent()
>  */
> public Boolean getBoolean(String name) {
> String s = this.get(name);
> return s != null ? Boolean.valueOf(s) : null;
> }
>
> /**
>  * Returns a value by name.
>  *
>  * @param name
>  *the name of the column to be retrieved.
>  * @return the column value, or {@code false} if the column name is not
> found
>  * @throws IllegalStateException
>  * if no header mapping was provided
>  * @throws IllegalArgumentException
>  * if the record is inconsistent
>  * @see #isConsistent()
>  */
> public boolean getBooleanPrimitive(String name) {
> return Boolean.parseBoolean(this.get(name));
> }
>
> Gary
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition<
> http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>

Re: [csv] record.get APIs for primitive types

[Paul Benedict]

You might want to think of a conversion addon package using Common
BeanUtils. That project is skilled at conversions from String and has
pluggable capability to customize conversion types.
On Aug 1, 2013 6:51 PM, "Paul Benedict"  wrote:

> None of these methods document exceptions if the conversion fails (eg, not
> an integer). Also, how strict is the conversion? Can "x" represent boolean
> false or is that an exception?
> On Aug 1, 2013 9:00 AM, "Gary Gregory"  wrote:
>
>> I would like to note this CSVRecord addition I am planning on:
>>
>> public Boolean getBoolean(String name) {
>> public boolean getBooleanPrimitive(String name)
>>
>> The method listings are at the end of this message.
>>
>> What I want to note here is that these are conversion methods and that the
>> record still stores the values internally as Strings. I do not want to
>> Javadoc the conversion in order to give us flexibility over representation
>> if we decide to change it in the future (caching or whatnot).
>>
>> I wanted to post here in CTR mode before I or others add APIs like
>> getLong() and getLongPrimitive(). Since this is a library, I do believe we
>> should end up providing such APIs at the record level for primitives.
>>
>> /**
>>  * Returns a value by name.
>>  *
>>  * @param name
>>  *the name of the column to be retrieved.
>>  * @return the column value, or {@code null} if the column name is not
>> found
>>  * @throws IllegalStateException
>>  * if no header mapping was provided
>>  * @throws IllegalArgumentException
>>  * if the record is inconsistent
>>  * @see #isConsistent()
>>  */
>> public Boolean getBoolean(String name) {
>> String s = this.get(name);
>> return s != null ? Boolean.valueOf(s) : null;
>> }
>>
>> /**
>>  * Returns a value by name.
>>  *
>>  * @param name
>>  *the name of the column to be retrieved.
>>  * @return the column value, or {@code false} if the column name is
>> not
>> found
>>  * @throws IllegalStateException
>>  * if no header mapping was provided
>>  * @throws IllegalArgumentException
>>  * if the record is inconsistent
>>  * @see #isConsistent()
>>  */
>> public boolean getBooleanPrimitive(String name) {
>> return Boolean.parseBoolean(this.get(name));
>> }
>>
>> Gary
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition<
>> http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>

Re: [csv] record.get APIs for primitive types

[Paul Benedict]

I can see that we should provide a decorator/delegate (CSVRecordWrapper?)
that has these additional methods and defers them to Beanutils. We should
use our other Commons project to accomplish the pluggable and configurable
conversion. Beanutils can be an optional Maven dependency. This doesn't
belong in Commons Langs, because that's where the functionality was before
migrating to its own BeanUtils project (circa 2001ish).
On Aug 1, 2013 7:06 PM, "James Carman"  wrote:

> Perhaps it belongs in Commons Lang?
>
> Anything like this that you try to put together is going to blow up
> really quickly, by the way (registering new converter types, etc.).  I
> don't see how having a few little helper methods in CSV is that big of
> an issue, personally.
>
> On Thu, Aug 1, 2013 at 7:59 PM, Paul Benedict
>  wrote:
> > You might want to think of a conversion addon package using Common
> > BeanUtils. That project is skilled at conversions from String and has
> > pluggable capability to customize conversion types.
> > On Aug 1, 2013 6:51 PM, "Paul Benedict"  wrote:
> >
> >> None of these methods document exceptions if the conversion fails (eg,
> not
> >> an integer). Also, how strict is the conversion? Can "x" represent
> boolean
> >> false or is that an exception?
> >> On Aug 1, 2013 9:00 AM, "Gary Gregory"  wrote:
> >>
> >>> I would like to note this CSVRecord addition I am planning on:
> >>>
> >>> public Boolean getBoolean(String name) {
> >>> public boolean getBooleanPrimitive(String name)
> >>>
> >>> The method listings are at the end of this message.
> >>>
> >>> What I want to note here is that these are conversion methods and that
> the
> >>> record still stores the values internally as Strings. I do not want to
> >>> Javadoc the conversion in order to give us flexibility over
> representation
> >>> if we decide to change it in the future (caching or whatnot).
> >>>
> >>> I wanted to post here in CTR mode before I or others add APIs like
> >>> getLong() and getLongPrimitive(). Since this is a library, I do
> believe we
> >>> should end up providing such APIs at the record level for primitives.
> >>>
> >>> /**
> >>>  * Returns a value by name.
> >>>  *
> >>>  * @param name
> >>>  *the name of the column to be retrieved.
> >>>  * @return the column value, or {@code null} if the column name is
> not
> >>> found
> >>>  * @throws IllegalStateException
> >>>  * if no header mapping was provided
> >>>  * @throws IllegalArgumentException
> >>>  * if the record is inconsistent
> >>>  * @see #isConsistent()
> >>>  */
> >>> public Boolean getBoolean(String name) {
> >>> String s = this.get(name);
> >>> return s != null ? Boolean.valueOf(s) : null;
> >>> }
> >>>
> >>> /**
> >>>  * Returns a value by name.
> >>>  *
> >>>  * @param name
> >>>  *the name of the column to be retrieved.
> >>>  * @return the column value, or {@code false} if the column name is
> >>> not
> >>> found
> >>>  * @throws IllegalStateException
> >>>  * if no header mapping was provided
> >>>  * @throws IllegalArgumentException
> >>>  * if the record is inconsistent
> >>>  * @see #isConsistent()
> >>>  */
> >>> public boolean getBooleanPrimitive(String name) {
> >>> return Boolean.parseBoolean(this.get(name));
> >>> }
> >>>
> >>> Gary
> >>>
> >>> --
> >>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> >>> Java Persistence with Hibernate, Second Edition<
> >>> http://www.manning.com/bauer3/>
> >>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> >>> Spring Batch in Action <http://www.manning.com/templier/>
> >>> 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: [csv] accessing primitives and other record values

[Paul Benedict]

Adrian, the conversions would be configurable. At least that's how I
envisioned it using existing BeanUtils functionality. Gary has a request
our to me to demo that.
On Aug 3, 2013 11:10 AM, "Adrian Crum" 
wrote:

> Inline...
>
> On 8/3/2013 9:05 AM, Gary Gregory wrote:
>
>> On Sat, Aug 3, 2013 at 11:50 AM, Adrian Crum <
>> adrian.crum@sandglass-**software.com >
>> wrote:
>>
>>  Have you considered recommending Commons Convert?
>>>
>>>  No: it is unreleased. Are you willing to help polish it to 1.0?
>>
>
> Aside from a pending bug fix, the code is complete. The project has been
> used by Apache OFBiz for years, so it is proven and stable. So, I don't
> know what additional steps are required to polish it. Having an official
> release would be wonderful.
>
>
>
>> Yes: I'd like to eat our own dog food.
>>
>> Gary
>>
>>  I agree that Java data type conversion is outside the scope of CSV.
>>>
>>>  What about a CSVRecord wrapper that delegates to [convert]?
>>
>
> What would that look like? From my experience, hard-coding conversions is
> not scalable. If an application needs to convert a CSV field to a custom
> type Foo, how will the wrapper accommodate that?
>
>
>
>> Gary
>>
>>
>>  -Adrian
>>>
>>>
>>> On 8/3/2013 8:36 AM, Gary Gregory wrote:
>>>
>>>  Hi All:

 I recently added these CSVRecord APIs: getBoolean(String),
 getInt(String),
 getLong(String), getBigInteger(String).

 Some people are OK with this, some consider this out of scope, some
 consider it not necessary for 1.0, some -1, some are worried about
 feature
 creep (default values, Calendar, Date, List, and so on), some think the
 Javadoc should be clearer.

 At the very least I think we should document how to access or convert
 typed
 values. We could:

 - Document the new APIs, or remove them AND:
 - Document how to use another Commons API
 - Document how to use another (non Commons) API
 - Document how to do it all yourself
 - Create a CSVRecrord wrapper class that contains all the APIs where the
 implementation may or may not delegate to another Commons API.

 No matter what, it's pretty obvious that this conversion code is going
 to
 exist somewhere, in the user's app, in [csv] or someplace else.

 We should make a plan such that if we do not provide this feature in
 1.0,
 we have a roadmap for our users.

 Gary


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

Re: [csv] accessing primitives and other record values

[Paul Benedict]

I'll have to look into what Beanutils requires since it's been sometime I
last directly dealt with it. I think it comes with basic Java conversions
but everything can be configured as needed.

I did not know about Commons Convert. Why "two" commons project that do the
same thing?

Paul


On Sat, Aug 3, 2013 at 11:25 AM, Adrian Crum <
adrian.c...@sandglass-software.com> wrote:

> Actually, I picture it like this: Commons CSV does not contain any
> conversions, and data type conversions are left to the application
> developer. We can recommend Commons Convert. The applications developer is
> free to create any wrappers/facades necessary to connect the two.
>
> -Adrian
>
>
> On 8/3/2013 9:18 AM, Paul Benedict wrote:
>
>> Adrian, the conversions would be configurable. At least that's how I
>> envisioned it using existing BeanUtils functionality. Gary has a request
>> our to me to demo that.
>> On Aug 3, 2013 11:10 AM, "Adrian Crum" > software.com >
>> wrote:
>>
>>  Inline...
>>>
>>> On 8/3/2013 9:05 AM, Gary Gregory wrote:
>>>
>>>  On Sat, Aug 3, 2013 at 11:50 AM, Adrian Crum <
>>>> adrian.crum@sandglass-**softwa**re.com <http://software.com> <
>>>> adrian.crum@sandglass-**software.com
>>>> >>
>>>>
>>>> wrote:
>>>>
>>>>   Have you considered recommending Commons Convert?
>>>>
>>>>>   No: it is unreleased. Are you willing to help polish it to 1.0?
>>>>>
>>>> Aside from a pending bug fix, the code is complete. The project has been
>>> used by Apache OFBiz for years, so it is proven and stable. So, I don't
>>> know what additional steps are required to polish it. Having an official
>>> release would be wonderful.
>>>
>>>
>>>
>>>  Yes: I'd like to eat our own dog food.
>>>>
>>>> Gary
>>>>
>>>>   I agree that Java data type conversion is outside the scope of CSV.
>>>>
>>>>>   What about a CSVRecord wrapper that delegates to [convert]?
>>>>>
>>>> What would that look like? From my experience, hard-coding conversions
>>> is
>>> not scalable. If an application needs to convert a CSV field to a custom
>>> type Foo, how will the wrapper accommodate that?
>>>
>>>
>>>
>>>  Gary
>>>>
>>>>
>>>>   -Adrian
>>>>
>>>>>
>>>>> On 8/3/2013 8:36 AM, Gary Gregory wrote:
>>>>>
>>>>>   Hi All:
>>>>>
>>>>>> I recently added these CSVRecord APIs: getBoolean(String),
>>>>>> getInt(String),
>>>>>> getLong(String), getBigInteger(String).
>>>>>>
>>>>>> Some people are OK with this, some consider this out of scope, some
>>>>>> consider it not necessary for 1.0, some -1, some are worried about
>>>>>> feature
>>>>>> creep (default values, Calendar, Date, List, and so on), some think
>>>>>> the
>>>>>> Javadoc should be clearer.
>>>>>>
>>>>>> At the very least I think we should document how to access or convert
>>>>>> typed
>>>>>> values. We could:
>>>>>>
>>>>>> - Document the new APIs, or remove them AND:
>>>>>> - Document how to use another Commons API
>>>>>> - Document how to use another (non Commons) API
>>>>>> - Document how to do it all yourself
>>>>>> - Create a CSVRecrord wrapper class that contains all the APIs where
>>>>>> the
>>>>>> implementation may or may not delegate to another Commons API.
>>>>>>
>>>>>> No matter what, it's pretty obvious that this conversion code is going
>>>>>> to
>>>>>> exist somewhere, in the user's app, in [csv] or someplace else.
>>>>>>
>>>>>> We should make a plan such that if we do not provide this feature in
>>>>>> 1.0,
>>>>>> we have a roadmap for our users.
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>>
>>>>>>   --**--**
>>>>>> --**
>>>>>>
>>>>> --**-
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apac**he.org<
>>>>> http://apache.org**>
>>>>> http://commons.apache.org><
>>>>> dev-unsubscribe@**commons.apache.org
>>>>> >
>>>>>
>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>
>>>>>
>>>>>
>>>>>  --**
>>> --**-
>>> To unsubscribe, e-mail: 
>>> dev-unsubscribe@commons.**apac**he.org<http://apache.org>
>>> 
>>> >
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@commons.**apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Cheers,
Paul

Re: [csv] accessing primitives and other record values

[Paul Benedict]

If Convert and BeanUtils do the same thing, I think Commons needs to figure
out how to solve this dilemma because duplicated functionality is usually
frowned upon here. For example, when Commons Lang began doing math, they
moved that to Commons Math (and the same thing happened for BeanUtils from
Lang).

If Convert is to be released, I think BeanUtils should get some refactoring
for a 2.0 release. They should harmonize but not duplicate functionality.

Paul


On Sat, Aug 3, 2013 at 11:58 AM, Gary Gregory wrote:

> On Sat, Aug 3, 2013 at 12:55 PM, Adrian Crum <
> adrian.c...@sandglass-software.com> wrote:
>
> > On 8/3/2013 9:49 AM, Gary Gregory wrote:
> >
> >> On Sat, Aug 3, 2013 at 12:10 PM, Adrian Crum <
> >> adrian.crum@sandglass-**software.com <
> adrian.c...@sandglass-software.com>>
> >> wrote:
> >>
> >>  Inline...
> >>>
> >>>
> >>> On 8/3/2013 9:05 AM, Gary Gregory wrote:
> >>>
> >>>  On Sat, Aug 3, 2013 at 11:50 AM, Adrian Crum <
>  adrian.crum@sandglass-**softwa**re.com  <
>  adrian.crum@sandglass-**software.com<
> adrian.c...@sandglass-software.com>
>  >>
> 
>  wrote:
> 
>    Have you considered recommending Commons Convert?
> 
> >   No: it is unreleased. Are you willing to help polish it to 1.0?
> >
>  Aside from a pending bug fix, the code is complete. The project has
> been
> >>> used by Apache OFBiz for years, so it is proven and stable. So, I don't
> >>> know what additional steps are required to polish it.
> >>>
> >>
> >> There's no user manual or FAQ, the Javadoc is thin. How do you get
> >> started?
> >>
> >
> >
> > I will try to build out the docs a little more. I think I need karma to
> > edit the Convert Wiki - adrianc.
> >
>
> The docs should be in SVN IMO, just like most components.
>
> Gary
>
>
> >
> >
> >
> >> More below.
> >>
> >>
> >>  Having an official release would be wonderful.
> >>>
> >>>
> >>>
> >>>
> >>>  Yes: I'd like to eat our own dog food.
> 
>  Gary
> 
>    I agree that Java data type conversion is outside the scope of CSV.
> 
> >   What about a CSVRecord wrapper that delegates to [convert]?
> >
>  What would that look like? From my experience, hard-coding conversions
> >>> is
> >>> not scalable. If an application needs to convert a CSV field to a
> custom
> >>> type Foo, how will the wrapper accommodate that?
> >>>
> >>>  It would not for now. This is just about primitives or basic JRE types
> >> like
> >> Number and Date (Calendar).
> >>
> >> Gary
> >>
> >>
> >>
> >>>
> >>>  Gary
> 
> 
>    -Adrian
> 
> >
> > On 8/3/2013 8:36 AM, Gary Gregory wrote:
> >
> >   Hi All:
> >
> >> I recently added these CSVRecord APIs: getBoolean(String),
> >> getInt(String),
> >> getLong(String), getBigInteger(String).
> >>
> >> Some people are OK with this, some consider this out of scope, some
> >> consider it not necessary for 1.0, some -1, some are worried about
> >> feature
> >> creep (default values, Calendar, Date, List, and so on), some think
> >> the
> >> Javadoc should be clearer.
> >>
> >> At the very least I think we should document how to access or
> convert
> >> typed
> >> values. We could:
> >>
> >> - Document the new APIs, or remove them AND:
> >> - Document how to use another Commons API
> >> - Document how to use another (non Commons) API
> >> - Document how to do it all yourself
> >> - Create a CSVRecrord wrapper class that contains all the APIs where
> >> the
> >> implementation may or may not delegate to another Commons API.
> >>
> >> No matter what, it's pretty obvious that this conversion code is
> going
> >> to
> >> exist somewhere, in the user's app, in [csv] or someplace else.
> >>
> >> We should make a plan such that if we do not provide this feature in
> >> 1.0,
> >> we have a roadmap for our users.
> >>
> >> Gary
> >>
> >>
> >>   --**--**
> >> --**
> >>
> > --**-
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apac**he.org<
> > http://apache.org**>
> > http://commons.apache.org><
> > dev-unsubscribe@**commons.apache.org<
> dev-unsubscr...@commons.apache.org>
> > >
> >
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
> >
> >  --**
> >>> --**-
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apac**he.org<
> http://apache.org>
> >>>  dev-unsubscr...@commons.apache.org>
> >>> >
> >>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>
> >>>
> >>>
> >>
> >
> > --**--**-
> > To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<
> dev-unsubscr...@commons.apache.org>
> > For additional comman

Re: inverseCumAccuracy is probably not necessary

[Paul Benedict]

I wonder how many were waiting in silence to see if someone else would
speak up for a rename.


On Tue, Aug 6, 2013 at 3:16 PM, Matt Benson  wrote:

> Actually I think by "function name" he was referring to the unfortunate
> English-language sexual innuendo incurred by the abbreviation of the word
> "cumulative" in the method name.
>
> Matt
>
>
> On Tue, Aug 6, 2013 at 2:27 PM, Phil Steitz  wrote:
>
> > On 8/6/13 10:00 AM, Konstantin Berlin wrote:
> > > Terrible function name also :)
> >
> > Can you suggest a better name for this parameter?  It is meant to
> > indicate the proscribed accuracy of the inverse cumulative
> > probability.  By "function name" I assume you are talking about the
> > name of the constructor parameter / configuration option.
> >
> > Phil
> > >
> > >
> > > On Tue, Aug 6, 2013 at 10:28 AM, Ajo Fod  wrote:
> > >
> > >> When does this become an issue?
> > >>
> > >> -Ajo
> > >>
> > >>
> > >> On Sun, Aug 4, 2013 at 9:42 AM, Phil Steitz 
> > wrote:
> > >>
> > >>> On 8/4/13 7:44 AM, Ajo Fod wrote:
> >  Guys,
> > 
> >  What is the use of inverseCumAccuracy when people want to
> instantiate
> > >> an
> >  AbstractRealDistribution with a random generator?
> >  org.apache.commons.math3.distribution.AbstractRealDistribution<
> > >>
> >
> http://commons.apache.org/proper/commons-math/apidocs/org/apache/commons/math3/distribution/AbstractRealDistribution.html
> > 
> >  I personally only seem to need to instantiate these objects with a
> >  RandomGenerator but never with the inverseCumAccuracy set to
> anything
> > >> but
> >  DEFAULT_INVERSE_ABSOLUTE_ACCURACY.
> > 
> >  Could we be better of with inverseCumAccuracy moved to another
> > >>> constructor?
> > >>>
> > >>> Good point.  We should take a careful look at which implementations
> > >>> actually use this parameter and remove it from constructors for
> > >>> those that don't.  I think some used to use it, but do not any
> > >>> longer - in particular the ones that no longer rely on the default
> > >>> inverse cum provided by AbstractRealDistribution.  The default impl
> > >>> uses a solver to directly invert the cdf and that is what this
> > >>> parameter is used for.  For the ones that do use it, it would also
> > >>> be convenient to provide constructors that include distribution
> > >>> parameters + random generator without this parameter.
> > >>>
> > >>> Phil
> >  Thanks,
> >  Ajo.
> > 
> > >>>
> > >>> -
> > >>> 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
> >
> >
>



-- 
Cheers,
Paul

Re: [CSV] Prohibit creation of more than one iterator over a CSVParser?

[Paul Benedict]

Perhaps we're going down the wrong path here. I think having an iterator()
and a parser conflict with each other. The former seems like a leaky
abstraction of the latter.  I would propose the parser uses an iterator
internally, or there's an API to get an iterator from a data source (but
not expose the parser).

Paul


On Tue, Aug 13, 2013 at 9:00 AM, Matt Benson  wrote:

> One approach I think I've actually used at some point is for the same class
> to implement both Iterator and Iterable, implementing #iterator() as
> `return this`.  While it seems a little weird, it's really just a more
> explicit reflection of what the current code is doing and so, at least in
> this case, it seems to me justifiable.  WDYT?
>
> Matt
>
>
> On Tue, Aug 13, 2013 at 8:39 AM, Benedikt Ritter 
> wrote:
>
> > We had that before but switched to Iterable to make it possible to use
> > CSVPaarser in foreach loops.
> >
> >
> > 2013/8/13 Matt Benson 
> >
> > > My thinking was more that CSVParser itself implements Iterator.
> > >
> > > Matt
> > > On Aug 13, 2013 2:59 AM, "Benedikt Ritter"  wrote:
> > >
> > > > Hi Matt,
> > > >
> > > >
> > > > 2013/8/12 Matt Benson 
> > > >
> > > > > As someone with no prior involvement with this component, and at
> risk
> > > of
> > > > > being hit by the digital tomatoes of the group, this seems to
> > indicate
> > > to
> > > > > me that once a parser definition has been joined to a source of
> > input,
> > > > the
> > > > > resulting object *is* the record iterator.  If there's no way to
> > twist
> > > > that
> > > > > into a comfortable API, I would tend to agree with Benedikt:
>  calling
> > > > > #iterator() a second time should do something like triggering an
> > > > > IllegalStateException().
> > > > >
> > > >
> > > > No tomatoes, don't worry ;-) feedback is always welcome.
> > > >
> > > > I'm not sure I understand what you're suggesting. Are you thinking of
> > > > something like:
> > > >
> > > > Iterator itr = CSVParser.parse(myCsvFile);
> > > >
> > > > CSVParser has some features that go beyond the capabilities of the
> > > > Iterator() interface. For example one can ask the parser for the
> > current
> > > > line number in your input and the current record number (which may
> not
> > be
> > > > the same for multi line records).
> > > > How about extending the Iterator interface?
> > > >
> > > > CSVIterator itr = CSVParser.parse(myCsvFile);
> > > >
> > > > and CSVIterator would look like:
> > > >
> > > > public interface CSVIterator extends Iterator {
> > > >// call the cool CSVParser stuff goes here
> > > > }
> > > >
> > > > But this wouldn't prevent more than one iterator over the same
> > source...
> > > >
> > > > Benedikt
> > > >
> > > >
> > > > >
> > > > > $0.02,
> > > > > Matt
> > > > >
> > > > >
> > > > > On Mon, Aug 12, 2013 at 4:43 PM, Gary Gregory <
> > garydgreg...@gmail.com
> > > > > >wrote:
> > > > >
> > > > > > On Mon, Aug 12, 2013 at 3:26 PM, Benedikt Ritter <
> > brit...@apache.org
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I've added a new test to CSVParser test case that shows what
> > > happens
> > > > if
> > > > > > > CSVParser.iterator() is called twice [1].
> > > > > > >
> > > > > > > This looks pretty strange to me. One iterator can eat up
> records
> > of
> > > > the
> > > > > > > other.
> > > > > > > Would it be better to throw an exception if iterator() is
> called
> > > more
> > > > > > than
> > > > > > > once?
> > > > > > >
> > > > > >
> > > > > > Yeah, there is something odd about the current impl. Wouldn't it
> be
> > > > > obvious
> > > > > > what can be done if there is an iterator ivar and the accessor
> just
> > > > > returns
> > > > > > it? It does not even have to be lazy initialized.
> > > > > >
> > > > > > Gary
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Benedikt
> > > > > > >
> > > > > > > [1] http://svn.apache.org/r1513228
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > http://people.apache.org/~britter/
> > > > > > > http://www.systemoutprintln.de/
> > > > > > > http://twitter.com/BenediktRitter
> > > > > > > http://github.com/britter
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > > > > > Java Persistence with Hibernate, Second Edition<
> > > > > > http://www.manning.com/bauer3/>
> > > > > > JUnit in Action, Second Edition <
> http://www.manning.com/tahchiev/>
> > > > > > Spring Batch in Action 
> > > > > > Blog: http://garygregory.wordpress.com
> > > > > > Home: http://garygregory.com/
> > > > > > Tweet! http://twitter.com/GaryGregory
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > http://people.apache.org/~britter/
> > > > http://www.systemoutprintln.de/
> > > > http://twitter.com/BenediktRitter
> > > > http://github.com/britter
> > > >
> > >
> >
> >
> >
> > --
> > http://people.apache.org/~britter/
> > http://www.systemoutprintln.de/
> > http://

Re: [convert] Automatic conversion based on proxies

[Paul Benedict]

The only danger of static methods is that you can't override them.
BeanUtils first suffered from this fate and they then made an instance
version (BeanUtils2). Just said plainly, you can't customize well using
factory classes/methods.


On Wed, Aug 14, 2013 at 3:04 PM, Emmanuel Bourg  wrote:

> Le 14/08/2013 17:39, Adrian Crum a écrit :
>
>  Instead of
>>
>> int columnInt = record.getValueAsInt(1);
>>
>> the developer would use
>>
>> Integer columnInt = Util.convertTo(record.**getValue(1), Integer.class);
>>
>
> +1 for the static method, that would allow the use of a static import and
> a very concise syntax like:
>
> Integer columnInt = to(Integer.class, record.getValue(1));
>
>
> That being said, [convert] could offer several patterns to perform type
> conversion, and the use of proxies could be one of them.
>
>
> Emmanuel Bourg
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@commons.**apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Cheers,
Paul

Re: [CSV] Prohibit creation of more than one iterator over a CSVParser?

[Paul Benedict]

Emmanuel, yes. Both the CVSParser and Iterator are two distinct designs.
Both are types of parsers here. So it's really a question of design. Do you
want your users to use the parser directly or work through the iterator or
both? But they shouldn't interfere with each other.

Example:
CVSParser p = record.parser();
Iterator i = record.iterator();

In the second example, Iterator is probably hiding the CVSParser
underneath. This render's the original question moot. You can have as many
concurrent parsers as you want with proper encapsulation.

Paul


On Wed, Aug 14, 2013 at 4:05 PM, Emmanuel Bourg  wrote:

> Le 14/08/2013 20:22, Benedikt Ritter a écrit :
>
>> Thanks for the input. Now is the time to talk about this kind of stuff.
>> I understand Matt's proposal and it should be relatively easy to
>> implement.
>>
>> However I see Paul's point but don't know yet how to develop the API the
>> way he suggests.
>> Paul can your point be summed up as: Either expose an iterator or a parser
>> but not both?
>>
>> What do others think? Sebb? Gary? Emmanuel?
>> This seems like one of the last issues on the road to 1.0
>>
>
> Throwing an IllegalArgumentException if iterator() is called more than
> once would make sense.
>
> Following Paul's idea, we could probably hide the parser completely and
> make it package private. The main entry point of the API would be
> CSVFormat.parse(Reader) returning an Iterable.
>
> The public methods of CSVParser aren't that useful:
>
> * close()/isClosed() : resource management can be done outside [csv]
>
> * getCurrentLineNumber() : to be moved into CSVRecord?
>
> * getHeaderMap() : removed or moved into CSVRecord?
>
> * getRecordNumber() : already available in CSVRecord
>
> * getRecords() : to be removed. I guess [collections] or [lang] already
> has a method turning an Iterable into a List?
>
>
> Emmanuel Bourg
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@commons.**apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Cheers,
Paul

[convert] BeanUtils vs. Convert

[Paul Benedict]

Two weeks ago, I mentioned that BeanUtils and Convert heavily overlap. Some
others agreed. Do we want to fold one project into the other? Or can we
find justification to have 2 separate conversion projects?

-- 
Cheers,
Paul

Re: [DISCUSS] API compatibility policy

[Paul Benedict]

A good resource if you didn't know it existed:
http://commons.apache.org/releases/versioning.html


On Tue, Oct 8, 2013 at 3:54 PM, Gary Gregory  wrote:

> On Tue, Oct 8, 2013 at 4:50 PM, Siegfried Goeschl
>  wrote:
> > That's a reasonable style of versioning :)
> >
> > I had many issues with binary compatibilty with a commons-email release
> due to changing the return value from void to a this reference plus some
> moving of constants. You basically end up with either many restrictions or
> creating major releases
>
> Then just create major releases! ;) Why would you not want to provide
> BC? Why add to the jar hell problem? I, the developer, have no control
> over how the API I provide will be used and distributed...
>
> G
>
> >
> > Cheers,
> >
> > Siegfried Goeschl
> >
> >> Am 08.10.2013 um 12:40 schrieb Torsten Curdt :
> >>
> >> Cannot remember which component from the top of my head - but it was
> >> related to package name changes.
> >>
> >> My style of thinking: x.y.z
> >>
> >> x - no compatibility
> >> y - source compatibility
> >> z - binary compatibility
> >>
> >> is simple and makes sense.
> >>
> >> It's OK to put some burden on the users when upgrading - as long as the
> >> expectations are set correctly.
> >> But I am pretty sure we discussed that before and some people did not
> agree.
> >>
> >> cheers,
> >> Torsten
> >>
> >>
> >>> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig 
> wrote:
> >>>
>  On 2013-10-08, Emmanuel Bourg wrote:
> 
>  Le 07/10/2013 20:14, Benedikt Ritter a écrit :
> >>>
> > - loosen API compatibility policy?
> >>>
>  This topic alone deserves its own thread I think.
> >>>
>  Ensuring binary/source compatibility is very important.
> >>>
> >>> +1
> >>>
> >>> I guess I've done too much ruby with "every bundle update runs the risk
> >>> of breaking everything" lately.  I really value the stability commons
> >>> provides.
> >>>
> >>> That being said, I'm sure there are cases where our policy seems
> >>> stricter than it needs to be - even though I haven't seen a really
> >>> difficult case in the one component I contribute to.
> >>>
> >>> Stefan
> >>>
> >>> -
> >>> 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
> >
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Cheers,
Paul

Re: [SCXML] Next major version number required package rename needed?

[Paul Benedict]

The dots aren't decimal separators and version numbers are not true
numbers. 0.9 goes to 0.10 goes to 0.11, etc. If they were true decimal
numbers, you couldn't have more than one dot.

0.9 to 1.0 is a major version jump. However, 0.X usually indicates
pre-release quality (i.e., not ready for production yet).

Paul




On Thu, Oct 10, 2013 at 7:40 PM, Niall Pemberton
wrote:

> I would bump to version 2.0 because I dont think its clear that going from
> 0.9 to 1.0 is a major version change - in my mind 0.9 seems to imply "we
> haven't quite completed everything we want to for 1.0"
>
> Niall
>
>
> On Fri, Oct 11, 2013 at 12:52 AM, James Carman
> wrote:
>
> > Now, this case is a bit weird, since we have released code in a < 1.0
> > version number.  So, the artifact/package will have to be scxml1,
> > which looks funky IMHO.  I guess that follows the pattern, though.
> >
> > On Thu, Oct 10, 2013 at 7:49 PM, Ate Douma  wrote:
> > > On 10/11/2013 01:41 AM, James Carman wrote:
> > >>
> > >> If you are breaking backward compatibility then you need to do the
> > renames
> > >> (package, and artifactId).
> > >
> > >
> > > That was my impression already.
> > > And I have no real issue with doing so.
> > >
> > > But again, when has this been decided and has it ever been formalized
> > > (written down) somewhere?
> > >
> > >
> > >>
> > >> I don't know if we ever landed on a "rule" about the new JDK level
> > >> scenario, though.
> > >
> > > Okay, maybe that was just an incorrect assumption.
> > >
> > > And it doesn't really matter as there will be breaking API changes
> needed
> > > for the next version of SCXML, so we'll have to bump the major version
> > > anyway.
> > >
> > >>
> > >> On Thursday, October 10, 2013, Ate Douma wrote:
> > >>
> > >>> On 10/11/2013 01:16 AM, Emmanuel Bourg wrote:
> > >>>
> >  Commons SCXML has only one reverse dependency in Maven Central,
> >  flexistate, so I wouldn't bother with the binary compatibility and
> > just
> >  keep the package as is.
> > 
> > >>>
> > >>> Hmm. That might be the only reverse dependency of artifacts also
> > deployed
> > >>> to Maven Central, but I'm pretty sure SCXML 0.9 is used in plenty of
> > >>> projects which might be impacted still.
> > >>>
> > >>> I would expect stronger arguments to decide yes/no if a package
> rename
> > is
> > >>> required or not. This would seem a bit (too) arbitrary to me.
> > >>>
> > >>> Mind you, I'd prefer not having to do a package rename, but I got the
> > >>> impression there are more explicit 'rules' when to do so.
> > >>>
> > >>> So I'd still would like to hear more explicitly if such a rule is
> > >>> defined,
> > >>> and if so how it is worded and where. But of course if there is none,
> > >>> fine
> > >>> by me :)
> > >>>
> > >>> Thanks, Ate
> > >>>
> > >>>
> > 
> > 
> http://mvnrepository.com/**artifact/commons-scxml/**commons-scxml/0.9
> > 
> > 
> >  Emmanuel Bourg
> > 
> > 
> > 
> > 
> > --**--**-
> > 
> >  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >  For additional commands, e-mail: dev-h...@commons.apache.org
> > 
> > 
> > >>>
> > >>>
> > --**--**-
> > >>>
> > >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > >>> For additional commands, e-mail: dev-h...@commons.apache.org
> > >>>
> > >>>
> > >>
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>



-- 
Cheers,
Paul

Re: [CHALLENGE] Move All of Commons to the Dormant

[Paul Benedict]

I don't like the idea of putting inactive components in the attic -- unless
there is some unreasonable length of time that goes by without any
development (3 years?). People who want to get things out of the attic are
usually a sole passionate fellow. Can a sole fellow unilaterally get a
component out of the attic? I wouldn't think so ... but if I am wrong, I
would drop my objection.


On Tue, Oct 15, 2013 at 7:59 AM, Emmanuel Bourg  wrote:

> Le 15/10/2013 14:35, Gary Gregory a écrit :
>
> > the web site can say "last released on -mm-dd, no new
> > releases planned".
>
> I like this idea, but unless you automate the site update it adds an
> extra manual step to the release process.
>
> Emmanuel Bourg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Cheers,
Paul

Re: [CHALLENGE] Move All of Commons to the Dormant

[Paul Benedict]

I am glad to hear being "dormant" is not the same thing as being in the
"attic"

I also prefer that being "dormant" doesn't cause a SVN/GitHub folder move.
The projects should just live where they are, even when sleeping. Only move
them if they actually go into an "attic"


On Thu, Oct 17, 2013 at 11:03 AM, Phil Steitz  wrote:

> On 10/17/13 5:52 AM, Christian Grobmeier wrote:
> > On 17 Oct 2013, at 2:39, Henri Yandell wrote:
> >
> >> On Wed, Oct 16, 2013 at 4:59 PM, sebb  wrote:
> >>
> >>> On 16 October 2013 12:25, Christian Grobmeier
> >>>  wrote:
>  If nobody is willing to put a component to "dormant" state,
>  then the
>  label doesn't make any sense. I would vote to remove the
>  dormant state in
>  general.
>  If we don't have any need of a specific component we can put it to
>  attic.apache.org too.
>  No need to duplicate things.
> >>>
> >>> AFAIK, the Attic is for entire TLPs only, not individual
> >>> components.
> >>
> >>
> >> There are XML subcomponents there.
> >>
> >> Jakarta ones went dormant iirc, but then moved over as
> >> subcomponents and
> >> not the overall umbrella. So I don't think there's a reason why a
> >> Commons
> >> component wouldn't fit.
> >
> > +1
> >
> > The attic is not only for TLPs.
> > I don't find the mail reference right now. But I was asked to put
> > log4cxx to the attic (sub component of Apache Logging).
>
> I think the "dormant" classification in Commons, should we decide to
> keep it (and I agree we should either agree to keep it and get it
> defined and updated or dump it) does not have to be the same as
> "retirement to the Attic."  I proposed above that we this just be a
> designation based on lack of current "committed committers" and
> things could go in and out of dormancy without any svn (or Git or
> whatever) moves, trips through the incubator or other heavyweight
> process.  Gary and others have pointed out that you might be able to
> accomplish the same thing by just keeping team lists up to date,
> prominently displaying last release date, etc. on the web site.
> Could be that is the best solution and we just dump the "dormant"
> concept altogether.  Whatever we decide to do, I agree with Hen that
> getting a clear picture of what people are now or working on /
> intent RSN to work on is good info to have in deciding among the
> alternatives.
>
> Phil
> >
> >
> > ---
> > http://www.grobmeier.de
> > @grobmeier
> > GPG: 0xA5CC90DB
> >
> > -
> > 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
>
>


-- 
Cheers,
Paul

Re: [lang] LANG-781

[Paul Benedict]

I don't think any duplication will occur if we follow simple rules. Unless
the object performs validation -- which can determined if an exception is
thrown on validation failure -- then you have a method for ObjectUtils;
otherwise it belongs in Validate.


On Fri, Oct 18, 2013 at 1:26 PM, Gary Gregory wrote:

> On Thu, Oct 17, 2013 at 3:24 PM, Matt Benson  wrote:
>
> > On Oct 17, 2013 3:22 AM, "Henri Yandell"  wrote:
> > >
> > > Matt/Gary:
> > >
> > > Are we able to move onwards with this issue?
> > >
> > > https://issues.apache.org/jira/browse/LANG-781
> > >
> > > You seemed in agreement. Are the ObjectUtils patches good to apply, and
> > > does the Validate patch need implementing? Should the validate part be
> > > split off as a separate issue?
> > >
> >
> > Original requestor wants a boolean so I guess the ObjectUtils patch is
> > necessary to satisfy. If we split off the Validate issue then it doesn't
> so
> > much matter when that gets done though I believe it's trivial.
> >
>
> What I would like to see is:
> - Validate stand on it's own as a validation too.
> - ObjectUtils be a home for things we think belong in java.lang.Object or
> Objects.
>
> This means some duplication is possible.
>
> Gary
>
>
> >
> > Matt
> >
> > > Hen
> >
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition<
> http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
Cheers,
Paul

Re: [lang] ImmutablePair is final

[Paul Benedict]

If you can subclass, the class will likely be mutable somehow (accessing
protected or package-private data?) -- even introducing new variables
exclusive to the subclass. The "final" keyword is used well here.


On Tue, Oct 22, 2013 at 12:15 PM, sebb  wrote:

> On 22 October 2013 18:10, Gary Gregory  wrote:
> > Hi All:
> >
> > Is there any reason we would want to keep ImmutablePair final?
>
> To stop mutable subclasses from being created?
>
> BTW, it's unfortunate that the fields are public; they should have
> been private (there are public getters).
>
> > Gary
> >
> > --
> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > Java Persistence with Hibernate, Second Edition<
> http://www.manning.com/bauer3/>
> > JUnit in Action, Second Edition 
> > Spring Batch in Action 
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Cheers,
Paul

Re: [lang] ImmutablePair is final

[Paul Benedict]

The safest approach is composition. It's the only way for the immutability
contract to be honored across development teams (Commons + end user).


On Wed, Oct 23, 2013 at 1:00 AM, Duncan Jones  wrote:

> On 23 Oct 2013 01:26, "Gary Gregory"  wrote:
> >
> > On Tue, Oct 22, 2013 at 4:53 PM, Duncan Jones  wrote:
> >
> > > On 22 October 2013 21:07, Gary Gregory  wrote:
> > > > On Tue, Oct 22, 2013 at 3:59 PM, Matt Benson 
> > > wrote:
> > > >
> > > >> So what is having a non-generic runtime class accomplishing for you?
> > > >>
> > > >
> > > > The subclass "is a kind of" pair AND it is domain typed to my app.
> > > >
> > > > Gary
> > >
> > > Sebb is correct - composition would work well here. You can still
> > > defer to the equals/hashcode from the underlying ImmutablePair as you
> > > appear to store no other state within the class.
> > >
> >
> > I could do it that way and end up with a hierarchy likeL
> >
> > - Lang final ImmutablePair
> > - My ImmutablePairProxy wraps an ImmutablePair
> > - My ImmutablePairProxyClass extends ImmutablePairProxy
> > - My ImmutablePairProxyClass extends ImmutablePairProxy
> >
> > It's doable but it feels more spaghetti like than subclassing
> ImmutablePair.
> >
> > Gary
>
> But that approach will suffer from the same problems discussed earlier. Any
> non final "immutable" class can be undone by a pesky subclass that doesn't
> obey the immutability, deliberately or accidentally.
>
> I guess it depends how much of a purist you are.
>
> A weaker alternative is to mark your inner Pair object as private (which it
> probably is) and mark all the public methods of ImmutablePairProxy as final
> too.
>
> Duncan
>
> > >
> > >
> > > >
> > > >
> > > >>
> > > >> Matt
> > > >>
> > > >>
> > > >> On Tue, Oct 22, 2013 at 2:29 PM, Gary Gregory <
> garydgreg...@gmail.com
> > > >> >wrote:
> > > >>
> > > >> >
> > > >> >
> > > >> >
> > > >> > Sent via the Samsung Galaxy Note® 3, an AT&T 4G LTE smartphone
> > > >> >
> > > >> >  Original message 
> > > >> > From: sebb
> > > >> > Date:10/22/2013 13:37 (GMT-05:00)
> > > >> > To: Commons Developers List
> > > >> > Subject: Re: [lang] ImmutablePair is final
> > > >> >
> > > >> > On 22 October 2013 18:33, Gary Gregory 
> > > wrote:
> > > >> > > On Tue, Oct 22, 2013 at 1:22 PM, Paul Benedict <
> > > pbened...@apache.org>
> > > >> > wrote:
> > > >> > >
> > > >> > >> If you can subclass, the class will likely be mutable somehow
> > > >> (accessing
> > > >> > >> protected or package-private data?) -- even introducing new
> > > variables
> > > >> > >> exclusive to the subclass. The "final" keyword is used well
> here.
> > > >> > >>
> > > >> > >
> > > >> > > Here is my use case for which I've cloned ImmutablePair into my
> own
> > > >> > package
> > > >> > > (yuck):
> > > >> >
> > > >> > Composition (rather than extension) would work better here surely?
> > > >> >
> > > >> > Surely indeed Shirley ;) (Airplane!)
> > > >> >
> > > >> > Right now I am getting hashCode and equals for free with the
> subclass
> > > >> > hack.
> > > >> >
> > > >> > Gary
> > > >> >
> > > >> >
> > > >> > > public final class ImmutableFooImmutableBarPair extends
> > > >> > > ImmutablePair {
> > > >> > >
> > > >> > > private static final long serialVersionUID = 123L;
> > > >> > >
> > > >> > > public ImmutableFooImmutableBarPair (final ImmutableFoo foo,
> > > final
> > > >> > > ImmutableBar bar) {
> > > >> > > super(Validate.notNull(nameMatch),
> > > Validate.notNull(article));
> > > >> > > }
> > > >> > >
> > > >>

Re: [compress] Strong Crypto in Tests

[Paul Benedict]

In my own research on strong crypto, I found out that US law allows strong
crypto to be exported for open source software. That was some provision
recently carved out in the last 10 years. I think there are some
limitations and procedures wrapped around it -- like submitting the URL to
the source code to the US Commerce Department -- but generally it's
allowed. However, this isn't legal advice :-) and just my own
understanding. I hope this helps.

With that said, I wouldn't commit any strong crypto code into Apache's SCM
without first getting assurance from the IP folks.

Paul


On Wed, Oct 23, 2013 at 8:54 AM, Stefan Bodewig  wrote:

> On 2013-10-23, Mark Fortner wrote:
>
> > As you're probably aware, aes is export restricted.
>
> Commons Compress already has a crypto notice, see also
> 
>
> 7z uses 256bit AES when encrypting so if we want to provide code that
> can read encrypted archives there is little choice which algorithms we
> support :-)
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Cheers,
Paul

Re: I need a map for long and double

[Paul Benedict]

I don't think anything like that exists. If your # of entries were
reasonable, a theoretical implementation could allocate a big long[] array
and hash into that. However, 150,000 is very large for an array; possible
but I never done it. So I think the only thing you can really rely on is
the standard Map


On Tue, Nov 5, 2013 at 7:39 PM, Gary Gregory  wrote:

> Hi All:
>
> I'm looking for a Map implementation that takes a String as a key and a
> long as the value (and another taking a double as the value). I'd rather
> not take the extra memory of using generic map with a Long object value hit
> since the maps will have up to 150,000 entries. That would save me... a meg
> for each map I am guestimating (on a 64-bit JVM). A meg here, a meg
> there...
>
> I did not see anything in [collections] or Google Guava.
>
> Thoughts?
>
> Gary
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition<
> http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
Cheers,
Paul

Re: I need a map for long and double

[Paul Benedict]

Same here. I didn't know this existed. Thanks.


On Tue, Nov 5, 2013 at 10:49 PM, Gary Gregory wrote:

> Thank you all for replying.
>
> HPPC looks promising and it's Apache 2 licensed. I'll give it a closer
> look.
>
> Gary
>
>
> On Tue, Nov 5, 2013 at 8:59 PM, Ted Dunning  wrote:
>
> > Trove is GPL (last I looked).
> >
> > Mahout has primitive collection implementations (and is obviously ASL).
> >
> > There are other implementations such as hppc (see
> > http://labs.carrotsearch.com/hppc.html )
> >
> > Mahout is a decent implementation, but I think that hppc has had a round
> or
> > two more optimization.
> >
> > And 150,000 entires in a table is not big for this sort of situation.
> >  Anything short of Integer.MAX_VALUE/small_factor should be fine.
> >
> >
> >
> >
> > On Tue, Nov 5, 2013 at 5:49 PM, Bruno P. Kinoshita <
> > brunodepau...@yahoo.com.br> wrote:
> >
> > > Maybe Trove's TObjectMapLong?
> > >
> > > [1]
> > >
> >
> http://trove4j.sourceforge.net/javadocs/gnu/trove/map/TObjectLongMap.html
> > >
> > >
> > > HTH,
> > >
> > > Bruno P. Kinoshita
> > > http://kinoshita.eti.br
> > > http://tupilabs.com
> > >
> > >
> > > >
> > > > From: Gary Gregory 
> > > >To: Commons Developers List 
> > > >Sent: Tuesday, November 5, 2013 11:39 PM
> > > >Subject: I need a map for long and double
> > > >
> > > >
> > > >Hi All:
> > > >
> > > >I'm looking for a Map implementation that takes a String as a key and
> a
> > > >long as the value (and another taking a double as the value). I'd
> rather
> > > >not take the extra memory of using generic map with a Long object
> value
> > > hit
> > > >since the maps will have up to 150,000 entries. That would save me...
> a
> > > meg
> > > >for each map I am guestimating (on a 64-bit JVM). A meg here, a meg
> > > there...
> > > >
> > > >I did not see anything in [collections] or Google Guava.
> > > >
> > > >Thoughts?
> > > >
> > > >Gary
> > > >
> > > >--
> > > >E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > > >Java Persistence with Hibernate, Second Edition<
> > > http://www.manning.com/bauer3/>
> > > >JUnit in Action, Second Edition 
> > > >Spring Batch in Action 
> > > >Blog: http://garygregory.wordpress.com
> > > >Home: http://garygregory.com/
> > > >Tweet! http://twitter.com/GaryGregory
> > > >
> > > >
> > > >
> > >
> >
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition<
> http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
Cheers,
Paul