[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-proxy-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 58 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-proxy-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -WARNING- Overriding Maven settings: 
[/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/proxy/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/gump_work/build_apache-commons_commons-proxy-test.html
Work Name: build_apache-commons_commons-proxy-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 14 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/proxy]
M2_HOME: /opt/maven2
-
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.factory.util.TestMethodSignature
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
Running org.apache.commons.proxy.provider.TestConstantProvider
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033 sec
Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.048 sec
Running org.apache.commons.proxy.interceptor.TestInterceptorChain
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec
Running org.apache.commons.proxy.invoker.TestNullInvoker
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec
Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec
Running org.apache.commons.proxy.exception.TestDelegateProviderException
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.invoker.TestChainInvoker
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec
Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory
Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.158 sec
Running org.apache.commons.proxy.exception.TestProxyFactoryException
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.interceptor.filter.TestReturnTypeFilter
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.provider.TestBeanProvider
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec

Results :

Tests in error: 
  testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker)

Tests run: 179, Failures: 0, Errors: 1, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] There are test failures.

Please refer to 
/srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports for the 
individual test results.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 12 seconds
[INFO] Finished at: Thu May 05 06:37:21 UTC 2011
[INFO] Final Memory: 24M/58M
[INFO] 
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/rss.xml
- Atom: 
http://vmgump.apache.or

[GUMP@vmgump]: Project commons-id (in module commons-sandbox) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-id has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 7 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-id :  Commons Identifier Package


Full details are available at:
http://vmgump.apache.org/gump/public/commons-sandbox/commons-id/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-id-05052011.jar] identifier set to project 
name
 -DEBUG- (Apache Gump generated) Apache Maven Properties in: 
/srv/gump/public/workspace/commons-sandbox/id/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-sandbox/id/project.xml
 -DEBUG- Maven project properties in: 
/srv/gump/public/workspace/commons-sandbox/id/project.properties
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/commons-sandbox/commons-id/gump_work/build_commons-sandbox_commons-id.html
Work Name: build_commons-sandbox_commons-id (Type: Build)
Work ended in a state of : Failed
Elapsed: 45 secs
Command Line: maven --offline jar 
[Working Directory: /srv/gump/public/workspace/commons-sandbox/id]
-
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 18.447 sec
[junit] Running org.apache.commons.id.uuid.state.NodeTest
[junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.319 sec
[junit] Running 
org.apache.commons.id.uuid.state.ReadOnlyResourceStateImplTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.487 sec
[junit] Running org.apache.commons.id.uuid.state.ReadWriteFileStateImplTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.424 sec
[junit] Running org.apache.commons.id.uuid.state.StateHelperTest
[junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.357 sec
[junit] Running org.apache.commons.id.uuid.state.InMemoryStateImplTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.333 sec
[junit] Running org.apache.commons.id.uuid.UUIDTest
[junit] Tests run: 17, Failures: 0, Errors: 0, Time elapsed: 0.275 sec
[junit] Running org.apache.commons.id.uuid.NodeManagerImplTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.436 sec
[junit] Running org.apache.commons.id.uuid.task.UUIDTaskTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.526 sec
[junit] Running org.apache.commons.id.uuid.clock.ThreadClockImplTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.252 sec
[junit] Running org.apache.commons.id.uuid.clock.SystemClockImplTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.251 sec
[junit] Running org.apache.commons.id.serial.AlphanumericGeneratorTest
[junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 0.267 sec
[junit] Running org.apache.commons.id.serial.LongGeneratorTest
[junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.259 sec
[junit] Running org.apache.commons.id.serial.PrefixedNumericGeneratorTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.262 sec
[junit] Running org.apache.commons.id.serial.NumericGeneratorTest
[junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.254 sec
[junit] Running 
org.apache.commons.id.serial.PrefixedLeftPaddedNumericGeneratorTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.249 sec
[junit] Running 
org.apache.commons.id.serial.PrefixedAlphanumericGeneratorTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.261 sec
[junit] Running 
org.apache.commons.id.serial.TimeBasedAlphanumericIdentifierGeneratorTest
[junit] Tests run: 12, Failures: 1, Errors: 0, Time elapsed: 0.753 sec
[junit] [ERROR] TEST 
org.apache.commons.id.serial.TimeBasedAlphanumericIdentifierGeneratorTest FAILED
[junit] Running org.apache.commons.id.CompositeIdentifierGeneratorTest
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.271 sec
[junit] Running org.apache.commons.id.ConstantIdentifierGeneratorTest
[junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.251 sec

BUILD FAILED
File.. /home/gump/.maven/cache/maven-test-plugin-1.6.2/plugin.jelly
Element... fail
Line.. 181
Column 54
There were test failures.
Total time: 43 seconds
Finished at: Thu May 05 06:36:05 UTC 2011

-

To subscribe to this informatio

[GUMP@vmgump]: Project commons-scxml-test (in module apache-commons) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-scxml-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 236 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-scxml-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -WARNING- Overriding Maven settings: 
[/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/scxml/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/scxml/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/gump_work/build_apache-commons_commons-scxml-test.html
Work Name: build_apache-commons_commons-scxml-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 18 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/scxml]
M2_HOME: /opt/maven2
-

---
 T E S T S
---
Running org.apache.commons.scxml.invoke.InvokeTestSuite
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.466 sec
Running org.apache.commons.scxml.test.TestingTestSuite
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec
Running org.apache.commons.scxml.env.EnvTestSuite
Tests run: 21, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.195 sec
Running org.apache.commons.scxml.SCXMLTestSuite
Tests run: 71, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.919 sec <<< 
FAILURE!
Running org.apache.commons.scxml.issues.IssuesTestSuite
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.371 sec
Running org.apache.commons.scxml.model.ModelTestSuite
Tests run: 78, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.335 sec <<< 
FAILURE!
Running org.apache.commons.scxml.env.faces.EnvFacesTestSuite
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.021 sec
Running org.apache.commons.scxml.semantics.SemanticsTestSuite
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
Running org.apache.commons.scxml.env.jsp.EnvJspTestSuite
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.046 sec
Running org.apache.commons.scxml.env.jexl.EnvJexlTestSuite
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.032 sec
Running org.apache.commons.scxml.env.servlet.EnvServletTestSuite
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec
Running org.apache.commons.scxml.io.IOTestSuite
Tests run: 30, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.372 sec

Results :

Failed tests: 
  
testNamespacePrefixedXPathsEL(org.apache.commons.scxml.NamespacePrefixedXPathsTest)
  testDatamodelSimultaneousJsp(org.apache.commons.scxml.model.DatamodelTest)

Tests run: 228, Failures: 2, Errors: 0, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] There are test failures.

Please refer to 
/srv/gump/public/workspace/apache-commons/scxml/target/surefire-reports for the 
individual test results.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 17 seconds
[INFO] Finished at: Thu May 05 05:14:47 UTC 2011
[INFO] Final Memory: 25M/61M
[INFO] 
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/rss.xml
- Atom: 
http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/atom.xml

== Gump Tracking Only ===
Produced by Apache Gump(TM) version 2.3.
Gump Run 1005052011, vmgump.apache.org:vmgump:1005052011
Gump E-mail Identifier (unique wi

Re: [lang] test jar for the next RC

[Gary Gregory]

On Wed, May 4, 2011 at 9:08 PM, Henri Yandell  wrote:

> No objections from me. Please dive right in.
>

Done.

Gary


>
> On Wed, May 4, 2011 at 8:31 AM, Gary Gregory 
> wrote:
> > Hi All:
> >
> > Any objections to adding test jar generation to the POM for the next RC?
> >
> > 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
>
>


-- 
Thank you,
Gary

http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory

Re: [lang] test jar for the next RC

[Henri Yandell]

No objections from me. Please dive right in.

On Wed, May 4, 2011 at 8:31 AM, Gary Gregory  wrote:
> Hi All:
>
> Any objections to adding test jar generation to the POM for the next RC?
>
> 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: [VOTE] [LANG] Release Commons Lang 3.0 (based on RC3)

[sebb]

On 4 May 2011 16:28, Gary Gregory  wrote:
> On Wed, May 4, 2011 at 6:46 AM, sebb  wrote:
>
>> On 4 May 2011 06:01, Gary Gregory  wrote:
>> > On Tue, May 3, 2011 at 11:36 PM, sebb  wrote:
>> >
>> >> On 4 May 2011 03:42, Gary Gregory  wrote:
>> >> > Now that I've can see my monitor clearly (no more fever!), I
>> understand
>> >> why
>> >> > this did not work.
>> >> >
>> >> > Running a standard test build for [lang] as documented on the Wiki
>> using:
>> >> >
>> >> > mvn clean deploy -Prelease -Ptest-deploy
>> >> >
>> >> > does not produce a test jar. It does so for [codec] because this is in
>> >> the
>> >> > POM:
>> >> >
>> >> >      
>> >> >        org.apache.maven.plugins
>> >> >        maven-jar-plugin
>> >> >        
>> >> >          
>> >> >            
>> >> >              test-jar
>> >> >            
>> >> >          
>> >> >        
>> >> >      
>> >> >
>> >> > But in common-parent, the crucial executions element is only in the
>> >> > "apache-release" profile.
>> >> >
>> >> > This was what we agreed upon a couple of weeks ago but it I did not
>> >> > understand the Maven magic enough to see what that meant.
>> >> >
>> >> > My goal is to generate the test jar for all commons releases, which
>> will
>> >> not
>> >> > happen since no one uses this "apache-release" profile.
>> >> >
>> >> > My questions then are:
>> >> >
>> >> > (1) Are there objections to include the Maven magic in the right place
>> to
>> >> > generate a test jar?
>> >> > (2) What is the point of the apache-release profile?
>> >>
>> >> http://maven.apache.org/asf-pom/#The_apache-release_Profile
>> >>
>> >> This was introduced in version 6 (according to the POM comments);
>> >> commons parent 13 was the first to include Apache POM 6+ (in fact 7).
>> >>
>> >> Commons Parent has included a "release" profile since version 1.
>> >>
>> >> AIUI this is has much the same purpose as the "apache-release" profile
>> >> so at some point we could switch to using that.
>> >>
>> >
>> > When I run:
>> >
>> > mvn clean deploy -Papache-release -Ptest-deploy
>> >
>> > the build hangs in maven-gpg-plugin
>> >
>> > ugh...
>> >
>> > My set up:
>> >
>> > Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
>> > Maven home: C:\Java\apache-maven-3.0.3\bin\..
>> > Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
>> > Java home: C:\Program Files\Java\jdk1.6.0_24\jre
>> > Default locale: en_US, platform encoding: Cp1252
>> > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>>
>> What gpg version do you use?
>>
>
>>gpg --version
> gpg (GnuPG) 1.4.11
> Copyright (C) 2010 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later >
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> Home: C:/Users/ggregory/AppData/Roaming/gnupg
> Supported algorithms:
> Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
> Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128,
>        CAMELLIA192, CAMELLIA256
> Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
> Compression: Uncompressed, ZIP, ZLIB, BZIP2
>
>
>>
>> Does "nmvn package gpg:sig" work?
>>
>
> Nope:

I thought I wrote:

>> Does "mvn package gpg:sign" work?

> [ERROR] Could not find goal 'sig' in plugin
> org.apache.maven.plugins:maven-gpg-plugin:1.2 among available goals
> sign-and-deploy-file, sign, help -> [Help 1]
>

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

Re: [lang] test jar for the next RC

[Simone Tripodi]

Thanks for the explanation Gary, very appreciated!!!
Have a nice day,
Simo

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



On Wed, May 4, 2011 at 8:41 PM, Gary Gregory  wrote:
> The immediate use I have is to be able to run the unit tests for a given
> component as part of the build for my product. For commons-lang and most
> commons projects, this is a low cost item time-wise.
>
> I want to know that the commons-foo jar will run on our build
> configurations, with our OSs, JVMs, locales, and other dependencies.
>
> We unit test our code, but we also use code that was unit tests in the past
> (any third party libraries.) but not on our setups.
>
> This may seem paranoid but it gets more tricky when you start piling on
> third party libraries one after the other
>
> Gary
>
> On Wed, May 4, 2011 at 11:50 AM, Simone Tripodi 
> wrote:
>
>> I don't see any blocking issue.
>> Can I you explain me please how this artifact can be reused? It's just
>> a matter of filling a lack in my knowledge, many thanks in advance!
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Wed, May 4, 2011 at 5:31 PM, Gary Gregory 
>> wrote:
>> > Hi All:
>> >
>> > Any objections to adding test jar generation to the POM for the next RC?
>> >
>> > 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
>>
>>
>
>
> --
> Thank you,
> Gary
>
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>

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

Re: [lang] Pair names still not right or consistent

[Gary Gregory]

On Wed, May 4, 2011 at 2:48 PM, Matt Benson  wrote:

> On Wed, May 4, 2011 at 12:45 PM, Gary Gregory 
> wrote:
> > On Wed, May 4, 2011 at 1:04 PM, Stephen Colebourne  >wrote:
> >
> >> On 4 May 2011 17:58, Gary Gregory  wrote:
> >> > I think we still have naming problems with the Pair class reflected in
> >> this
> >> > Javadoc fragment:
> >> >
> >> >  * @param  the first element type
> >> >  * @param  the second element type
> >> >
> >> > Either we call them L left and R right, or we call them F first and S
> >> > second, but mixing both is not good IMO.
> >> >
> >> > My preference is for K key and V value.
> >>
> >> Key and value implies a relationship between the two parts of the pair
> >> (the key somehow describes the value), which we cannot do
> >> (implementing Map.Entry is for convenience, not for any other reason).
> >> Either first/second or left/right are valid choices. At OpenGamma we
> >> use first/second but are able to change to left/right if this class is
> >> released.
> >>
> >
> > I think I like first and second better because we are in a package called
> > tuple after all.
> >
> > When I see left and right, I think of assignments. Why not top and bottom
> > too then? Just kidding.
> >
>
> Dee and Dum, ad nauseum...  left/right sit nicely with me as I don't
> place any real priority of one element over the other, which I think
> numeric names denote.  I think I like them for their monosyllabicity
> as well.  That said, http://en.wikipedia.org/wiki/Tuple defines a
> tuple's elements as being ordered, thus invalidating half of my
> argument.  Are there any equivalents to first/second that are nice and
> short?
>

One, Two?

G

>
> Matt
>
> >
> >>
> >> > I still do not like Pair as a name because a pair is: two identical,
> >> > similar, or corresponding things that are matched for use together: a
> >> pair
> >> > of gloves; a pair of earrings.
> >> > (http://dictionary.reference.com/browse/pair)
> >> >
> >> > We clearly break this common sense definition.
> >>
> >> I understand that from an English language POV, but Java devs all over
> >> know this as a pair. No other name will do I'm afraid.
> >>
> >
> > I'll let it be then.
> >
> > Gary
> >
> >>
> >> 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
> >
>
> -
> 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: [lang] Pair names still not right or consistent

[Matt Benson]

On Wed, May 4, 2011 at 12:45 PM, Gary Gregory  wrote:
> On Wed, May 4, 2011 at 1:04 PM, Stephen Colebourne 
> wrote:
>
>> On 4 May 2011 17:58, Gary Gregory  wrote:
>> > I think we still have naming problems with the Pair class reflected in
>> this
>> > Javadoc fragment:
>> >
>> >  * @param  the first element type
>> >  * @param  the second element type
>> >
>> > Either we call them L left and R right, or we call them F first and S
>> > second, but mixing both is not good IMO.
>> >
>> > My preference is for K key and V value.
>>
>> Key and value implies a relationship between the two parts of the pair
>> (the key somehow describes the value), which we cannot do
>> (implementing Map.Entry is for convenience, not for any other reason).
>> Either first/second or left/right are valid choices. At OpenGamma we
>> use first/second but are able to change to left/right if this class is
>> released.
>>
>
> I think I like first and second better because we are in a package called
> tuple after all.
>
> When I see left and right, I think of assignments. Why not top and bottom
> too then? Just kidding.
>

Dee and Dum, ad nauseum...  left/right sit nicely with me as I don't
place any real priority of one element over the other, which I think
numeric names denote.  I think I like them for their monosyllabicity
as well.  That said, http://en.wikipedia.org/wiki/Tuple defines a
tuple's elements as being ordered, thus invalidating half of my
argument.  Are there any equivalents to first/second that are nice and
short?

Matt

>
>>
>> > I still do not like Pair as a name because a pair is: two identical,
>> > similar, or corresponding things that are matched for use together: a
>> pair
>> > of gloves; a pair of earrings.
>> > (http://dictionary.reference.com/browse/pair)
>> >
>> > We clearly break this common sense definition.
>>
>> I understand that from an English language POV, but Java devs all over
>> know this as a pair. No other name will do I'm afraid.
>>
>
> I'll let it be then.
>
> Gary
>
>>
>> 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
>

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

Re: [lang] test jar for the next RC

[Gary Gregory]

The immediate use I have is to be able to run the unit tests for a given
component as part of the build for my product. For commons-lang and most
commons projects, this is a low cost item time-wise.

I want to know that the commons-foo jar will run on our build
configurations, with our OSs, JVMs, locales, and other dependencies.

We unit test our code, but we also use code that was unit tests in the past
(any third party libraries.) but not on our setups.

This may seem paranoid but it gets more tricky when you start piling on
third party libraries one after the other

Gary

On Wed, May 4, 2011 at 11:50 AM, Simone Tripodi wrote:

> I don't see any blocking issue.
> Can I you explain me please how this artifact can be reused? It's just
> a matter of filling a lack in my knowledge, many thanks in advance!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Wed, May 4, 2011 at 5:31 PM, Gary Gregory 
> wrote:
> > Hi All:
> >
> > Any objections to adding test jar generation to the POM for the next RC?
> >
> > 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
>
>


-- 
Thank you,
Gary

http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory

Re: [lang] Pair names still not right or consistent

[Gary Gregory]

On Wed, May 4, 2011 at 1:04 PM, Stephen Colebourne wrote:

> On 4 May 2011 17:58, Gary Gregory  wrote:
> > I think we still have naming problems with the Pair class reflected in
> this
> > Javadoc fragment:
> >
> >  * @param  the first element type
> >  * @param  the second element type
> >
> > Either we call them L left and R right, or we call them F first and S
> > second, but mixing both is not good IMO.
> >
> > My preference is for K key and V value.
>
> Key and value implies a relationship between the two parts of the pair
> (the key somehow describes the value), which we cannot do
> (implementing Map.Entry is for convenience, not for any other reason).
> Either first/second or left/right are valid choices. At OpenGamma we
> use first/second but are able to change to left/right if this class is
> released.
>

I think I like first and second better because we are in a package called
tuple after all.

When I see left and right, I think of assignments. Why not top and bottom
too then? Just kidding.


>
> > I still do not like Pair as a name because a pair is: two identical,
> > similar, or corresponding things that are matched for use together: a
> pair
> > of gloves; a pair of earrings.
> > (http://dictionary.reference.com/browse/pair)
> >
> > We clearly break this common sense definition.
>
> I understand that from an English language POV, but Java devs all over
> know this as a pair. No other name will do I'm afraid.
>

I'll let it be then.

Gary

>
> 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: [lang] Pair names still not right or consistent

[James Ring]

Hey,

On Wed, May 4, 2011 at 9:58 AM, Gary Gregory  wrote:
> Hi All:
>
> I think we still have naming problems with the Pair class reflected in this
> Javadoc fragment:
>
>  * @param  the first element type
>  * @param  the second element type
>
> Either we call them L left and R right, or we call them F first and S
> second, but mixing both is not good IMO.

First and second is better, a Pair is an instance of a 2-tuple, which
is an ordered list of elements. Left and right is no good IMO.

> My preference is for K key and V value.
>
> I still do not like Pair as a name because a pair is: two identical,
> similar, or corresponding things that are matched for use together: a pair
> of gloves; a pair of earrings.
> (http://dictionary.reference.com/browse/pair)
>
> We clearly break this common sense definition.

This is not the common definition in math and computer science.

> Tuple is better, Association is better (if wordier.)
>
> Why is Pair a good name?

A Pair is a 2-tuple, not a tuple. OrderedPair or TwoTuple might be
more "accurate" names but I think Pair is very descriptive, short and
sweet.

> Writing Pair.of(lastName, address) reads ugly and wrong to me. It feels like
> I am writing a bug or using the API incorrectly.

How does that sound wrong? I think it reads rather nicely.

> The association, correspondence, tuple, whatever you call it, of these two
> values is just not a pair of anything. Anything but java.lang.Object... but
> that's not even true since null is not an Object.
>
> --
> Thank you,
> Gary

Regards,
James

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

Re: [lang] Pair names still not right or consistent

[Stephen Colebourne]

On 4 May 2011 17:58, Gary Gregory  wrote:
> I think we still have naming problems with the Pair class reflected in this
> Javadoc fragment:
>
>  * @param  the first element type
>  * @param  the second element type
>
> Either we call them L left and R right, or we call them F first and S
> second, but mixing both is not good IMO.
>
> My preference is for K key and V value.

Key and value implies a relationship between the two parts of the pair
(the key somehow describes the value), which we cannot do
(implementing Map.Entry is for convenience, not for any other reason).
Either first/second or left/right are valid choices. At OpenGamma we
use first/second but are able to change to left/right if this class is
released.

> I still do not like Pair as a name because a pair is: two identical,
> similar, or corresponding things that are matched for use together: a pair
> of gloves; a pair of earrings.
> (http://dictionary.reference.com/browse/pair)
>
> We clearly break this common sense definition.

I understand that from an English language POV, but Java devs all over
know this as a pair. No other name will do I'm afraid.

Stephen

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

[lang] Pair names still not right or consistent

[Gary Gregory]

Hi All:

I think we still have naming problems with the Pair class reflected in this
Javadoc fragment:

 * @param  the first element type
 * @param  the second element type

Either we call them L left and R right, or we call them F first and S
second, but mixing both is not good IMO.

My preference is for K key and V value.

I still do not like Pair as a name because a pair is: two identical,
similar, or corresponding things that are matched for use together: a pair
of gloves; a pair of earrings.
(http://dictionary.reference.com/browse/pair)

We clearly break this common sense definition.

Tuple is better, Association is better (if wordier.)

Why is Pair a good name?

Writing Pair.of(lastName, address) reads ugly and wrong to me. It feels like
I am writing a bug or using the API incorrectly.

The association, correspondence, tuple, whatever you call it, of these two
values is just not a pair of anything. Anything but java.lang.Object... but
that's not even true since null is not an Object.

-- 
Thank you,
Gary

http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory

Re: [Validator] Localhost and email/domain validation

[Phil Steitz]

On 5/3/11 1:06 AM, Nick Burch wrote:
> On Mon, 4 Apr 2011, Nick Burch wrote:
>> On Mon, 28 Mar 2011, Nick Burch wrote:
>>> At the moment, the Email Validator considers @localhost email
>>> addresses to be invalid, due to the Domain Validator not
>>> considering it to be valid.
>>>
>>> Initially I thought this was wrong for all cases, so I opened
>>> VALIDATOR-292 and attached a patch that fixed this. However,
>>> after a bit more thinking and some discussions with a friend who
>>> also uses the email validator, I began to think it might need to
>>> be configurable. For a development setup, and possibly also for
>>> an intranet setup, you likely do want @localhost email addresses
>>> to be considered valid. You possibly also want to allow
>>> @machinename ones too. However, for a public facing internet app
>>> setup you likely wouldn't want that.
>>>
>>> What do people think on this? Should the Email Validator accept
>>> @localhost by default? And if not, what's the best way to allow
>>> the user to indicate that they do want that - another method (eg
>>> isValidLocal), overloading (eg isValid(String, boolean
>>> acceptLocal) or something else?
>>
>> Any takers on this? I'm happy to re-work my patch if required,
>> but if the silence means people are happy with @localhost being
>> accepted as valid, then my existing patch could be applied as-is.
>
> Anyone got an opinion on which way to go with this?
>
> Nick

Sorry, Nick, but the repeated non-response here indicates that
[validator] is effectively dead. 

Is anyone willing to help get these patches applied and move
[validator] forward, or should we move it to dormant?

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: [lang] test jar for the next RC

[Simone Tripodi]

I don't see any blocking issue.
Can I you explain me please how this artifact can be reused? It's just
a matter of filling a lack in my knowledge, many thanks in advance!
Simo

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



On Wed, May 4, 2011 at 5:31 PM, Gary Gregory  wrote:
> Hi All:
>
> Any objections to adding test jar generation to the POM for the next RC?
>
> 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: [VOTE] [LANG] Release Commons Lang 3.0 (based on RC3)

[Stephen Colebourne]

On 4 May 2011 16:23, Gary Gregory  wrote:
> Ah, well, it would make it easier to port my current code: create subclasses
> with the desired formatting and replace package names. Each subclass would
> call toString(format) and that's it. The alternative is to either call
> toString(format) from the call sites (sure, I could refactor that in a Utils
> class) or have my factory classes create pair wrappers. But it seems easier
> to keep reusing the current code than creating wrappers. If the class is
> final, I have to go the Utils route, I do not have the choice.
>
> I just do not see the point of hand-cuffing users by making the class final.
> I can always find new ways of shooting myself in the foot... ;)

Most of the time, open source should avoid final, because it places an
unecessary burden on users. However, the phrase "immutable" has very
specific meaning. BigDecimal and BigInteger are non-final "immutable"
classes, and secure code must clone them to be absolutely safe. [lang]
should follow best practice in Java, and "immutable" really does have
a specific meaning.

For your case, I would expect you to subclass Pair and create your own
class with your own format. This is no different to what I will need
to do here at OpenGamma to replace our pairs (now public and open
source!)
http://docs-static.opengamma.com/Latest%20Version/java/javadocs/com/opengamma/util/tuple/package-summary.html

Stephen

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

[lang] test jar for the next RC

[Gary Gregory]

Hi All:

Any objections to adding test jar generation to the POM for the next RC?

Thank you,
Gary

http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory

Re: [VOTE] [LANG] Release Commons Lang 3.0 (based on RC3)

[Gary Gregory]

On Wed, May 4, 2011 at 6:46 AM, sebb  wrote:

> On 4 May 2011 06:01, Gary Gregory  wrote:
> > On Tue, May 3, 2011 at 11:36 PM, sebb  wrote:
> >
> >> On 4 May 2011 03:42, Gary Gregory  wrote:
> >> > Now that I've can see my monitor clearly (no more fever!), I
> understand
> >> why
> >> > this did not work.
> >> >
> >> > Running a standard test build for [lang] as documented on the Wiki
> using:
> >> >
> >> > mvn clean deploy -Prelease -Ptest-deploy
> >> >
> >> > does not produce a test jar. It does so for [codec] because this is in
> >> the
> >> > POM:
> >> >
> >> >  
> >> >org.apache.maven.plugins
> >> >maven-jar-plugin
> >> >
> >> >  
> >> >
> >> >  test-jar
> >> >
> >> >  
> >> >
> >> >  
> >> >
> >> > But in common-parent, the crucial executions element is only in the
> >> > "apache-release" profile.
> >> >
> >> > This was what we agreed upon a couple of weeks ago but it I did not
> >> > understand the Maven magic enough to see what that meant.
> >> >
> >> > My goal is to generate the test jar for all commons releases, which
> will
> >> not
> >> > happen since no one uses this "apache-release" profile.
> >> >
> >> > My questions then are:
> >> >
> >> > (1) Are there objections to include the Maven magic in the right place
> to
> >> > generate a test jar?
> >> > (2) What is the point of the apache-release profile?
> >>
> >> http://maven.apache.org/asf-pom/#The_apache-release_Profile
> >>
> >> This was introduced in version 6 (according to the POM comments);
> >> commons parent 13 was the first to include Apache POM 6+ (in fact 7).
> >>
> >> Commons Parent has included a "release" profile since version 1.
> >>
> >> AIUI this is has much the same purpose as the "apache-release" profile
> >> so at some point we could switch to using that.
> >>
> >
> > When I run:
> >
> > mvn clean deploy -Papache-release -Ptest-deploy
> >
> > the build hangs in maven-gpg-plugin
> >
> > ugh...
> >
> > My set up:
> >
> > Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
> > Maven home: C:\Java\apache-maven-3.0.3\bin\..
> > Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
> > Java home: C:\Program Files\Java\jdk1.6.0_24\jre
> > Default locale: en_US, platform encoding: Cp1252
> > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>
> What gpg version do you use?
>

>gpg --version
gpg (GnuPG) 1.4.11
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: C:/Users/ggregory/AppData/Roaming/gnupg
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128,
CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2


>
> Does "nmvn package gpg:sig" work?
>

Nope:

[ERROR] Could not find goal 'sig' in plugin
org.apache.maven.plugins:maven-gpg-plugin:1.2 among available goals
sign-and-deploy-file, sign, help -> [Help 1]

Gary


>
> > Gary
> >
> >>
> >> Try using that goal and see.
> >>
> >> > Thank you,
> >> > Gary
> >> >
> >> > On Fri, Apr 29, 2011 at 4:56 PM, Henri Yandell 
> >> wrote:
> >> >
> >> >> Not a clue. One didn't get created.
> >> >>
> >> >> Hen
> >> >>
> >> >> On Fri, Apr 29, 2011 at 10:15 AM, Gary Gregory <
> garydgreg...@gmail.com>
> >> >> wrote:
> >> >> > Hi Hen,
> >> >> >
> >> >> > I was expecting to see a test jar in the deliverables, which is one
> of
> >> >> the
> >> >> > things commons-parent 21 brings to the table.
> >> >> >
> >> >> > What am I missing?
> >> >> >
> >> >> > Gary
> >> >> >
> >> >> > On Fri, Apr 29, 2011 at 2:47 AM, Henri Yandell  >
> >> >> wrote:
> >> >> >
> >> >> >> Lang is ready to consider 3.0 release again.
> >> >> >>
> >> >> >> RC3 is available here:
> >> >> >>
> >> >> >>  http://people.apache.org/~bayard/commons-lang3-3.0-RC3/
> >> >> >>
> >> >> >> Maven artifacts:
> >> >> >>
> >> >> >>  http://people.apache.org/~bayard/commons-lang3-3.0-RC3/maven/
> >> >> >>
> >> >> >> Website:
> >> >> >>
> >> >> >>  http://people.apache.org/~bayard/commons-lang3-3.0-RC3/site/
> >> >> >>
> >> >> >> Note that there is a 2.6->3.0 Clirr report in the site that may
> prove
> >> >> >> useful:
> >> >> >>
> >> >> >>
> >> >> >>
> >> >>
> >>
> http://people.apache.org/~bayard/commons-lang3-3.0-RC3/site/lang2-lang3-clirr--report.html
> >> >> >>
> >> >> >> This vote will close no sooner than in 72 hours time, 0700 GMT
> 2-May
> >> >> 2011.
> >> >> >>
> >> >> >> 
> >> >> >>   [ ] +1
> >> >> >>   [ ] -1, with reason
> >> >> >> 
> >> >> >>
> >> >> >> Hen
> >> >> >>
> >> >> >>
> -
> >> >> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> >> >

Re: [VOTE] [LANG] Release Commons Lang 3.0 (based on RC3)

[Gary Gregory]

On Wed, May 4, 2011 at 10:21 AM, Matt Benson  wrote:

> On Wed, May 4, 2011 at 8:14 AM, Gary Gregory 
> wrote:
> > On May 4, 2011, at 8:36, Matt Benson  wrote:
> >
> >> On Wed, May 4, 2011 at 5:39 AM, Stephen Colebourne <
> scolebou...@joda.org> wrote:
> >>> (review now back from holiday)
> >>>
> >>> -1
> >> [SNIP]
> >>> I'm still looking for ImmutablePair to be final too, but perhaps I
> >>> missed the conclusion of that debate... (NOT DONE in SVN)
> >>>
> >>
> >> Gary, now that you have toString(format) back, can you function with
> this?
> >
> > Yes. I do not need that class to be Formattable.
>
> The question was whether you need it to be extensible.  ;)
>

Ah, well, it would make it easier to port my current code: create subclasses
with the desired formatting and replace package names. Each subclass would
call toString(format) and that's it. The alternative is to either call
toString(format) from the call sites (sure, I could refactor that in a Utils
class) or have my factory classes create pair wrappers. But it seems easier
to keep reusing the current code than creating wrappers. If the class is
final, I have to go the Utils route, I do not have the choice.

I just do not see the point of hand-cuffing users by making the class final.
I can always find new ways of shooting myself in the foot... ;)

Gary


> Matt
>
> >
> > Gary
> >
> >>
> >> Matt
> >>
> >>> I also made some minor javadoc changes.
> >>>
> >>> Stephen
> >>>
> >>>
> >>>
> >>> On 29 April 2011 07:47, Henri Yandell  wrote:
>  Lang is ready to consider 3.0 release again.
> 
>  RC3 is available here:
> 
>   http://people.apache.org/~bayard/commons-lang3-3.0-RC3/
> 
>  Maven artifacts:
> 
>   http://people.apache.org/~bayard/commons-lang3-3.0-RC3/maven/
> 
>  Website:
> 
>   http://people.apache.org/~bayard/commons-lang3-3.0-RC3/site/
> 
>  Note that there is a 2.6->3.0 Clirr report in the site that may prove
> useful:
> 
> 
> http://people.apache.org/~bayard/commons-lang3-3.0-RC3/site/lang2-lang3-clirr--report.html
> 
>  This vote will close no sooner than in 72 hours time, 0700 GMT 2-May
> 2011.
> 
>  
>    [ ] +1
>    [ ] -1, with reason
>  
> 
>  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
> >
> >
>
> -
> 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: [VOTE] [LANG] Release Commons Lang 3.0 (based on RC3)

[Matt Benson]

On Wed, May 4, 2011 at 8:14 AM, Gary Gregory  wrote:
> On May 4, 2011, at 8:36, Matt Benson  wrote:
>
>> On Wed, May 4, 2011 at 5:39 AM, Stephen Colebourne  
>> wrote:
>>> (review now back from holiday)
>>>
>>> -1
>> [SNIP]
>>> I'm still looking for ImmutablePair to be final too, but perhaps I
>>> missed the conclusion of that debate... (NOT DONE in SVN)
>>>
>>
>> Gary, now that you have toString(format) back, can you function with this?
>
> Yes. I do not need that class to be Formattable.

The question was whether you need it to be extensible.  ;)

Matt

>
> Gary
>
>>
>> Matt
>>
>>> I also made some minor javadoc changes.
>>>
>>> Stephen
>>>
>>>
>>>
>>> On 29 April 2011 07:47, Henri Yandell  wrote:
 Lang is ready to consider 3.0 release again.

 RC3 is available here:

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

 Maven artifacts:

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

 Website:

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

 Note that there is a 2.6->3.0 Clirr report in the site that may prove 
 useful:

  http://people.apache.org/~bayard/commons-lang3-3.0-RC3/site/lang2-lang3-clirr--report.html

 This vote will close no sooner than in 72 hours time, 0700 GMT 2-May 2011.

 
   [ ] +1
   [ ] -1, with reason
 

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

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

Re: FormattableUtils

[Gary Gregory]

On May 4, 2011, at 9:02, Stephen Colebourne  wrote:

> On 4 May 2011 13:47, Matt Benson  wrote:
>> At some point Hen mentioned the idea of a PairFormat class.  I don't
>> think this is a bad idea, but the parsing capabilities of such a beast
>> would be minimal to nonexistent, and it still doesn't seem that it
>> would be configurable in a simple way without doing the equivalent of
>> String.format("", left, right).  At this point I am still not sure
>> what is the right mechanism for providing custom string
>> representations of Pair in the simplest and most elegant possible way.
>>  Have any ideas?

Nothing small and simple. Adding formatting to a pair smells like
mixing a view in a model.

Cleanly separating model and view leads to code that starts to feel
outside the scope of lang. Unless we started to need to format pairs
all over the place.

Btw, isn't a range a pair?

Gary
>
> Not really.
>
> toString(format) does the job of custom formatting pretty well.
> Anything else is a wrapper around that which feels pretty unecessary.
>
> Thus, I'd like to make Pair no longer implement Formattable (BTW, I
> don't think anything in the JDK implements Formattable, so its a weird
> interface).
>
> Stephen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [VOTE] [LANG] Release Commons Lang 3.0 (based on RC3)

[Gary Gregory]

On May 4, 2011, at 8:36, Matt Benson  wrote:

> On Wed, May 4, 2011 at 5:39 AM, Stephen Colebourne  
> wrote:
>> (review now back from holiday)
>>
>> -1
> [SNIP]
>> I'm still looking for ImmutablePair to be final too, but perhaps I
>> missed the conclusion of that debate... (NOT DONE in SVN)
>>
>
> Gary, now that you have toString(format) back, can you function with this?

Yes. I do not need that class to be Formattable.

Gary

>
> Matt
>
>> I also made some minor javadoc changes.
>>
>> Stephen
>>
>>
>>
>> On 29 April 2011 07:47, Henri Yandell  wrote:
>>> Lang is ready to consider 3.0 release again.
>>>
>>> RC3 is available here:
>>>
>>>  http://people.apache.org/~bayard/commons-lang3-3.0-RC3/
>>>
>>> Maven artifacts:
>>>
>>>  http://people.apache.org/~bayard/commons-lang3-3.0-RC3/maven/
>>>
>>> Website:
>>>
>>>  http://people.apache.org/~bayard/commons-lang3-3.0-RC3/site/
>>>
>>> Note that there is a 2.6->3.0 Clirr report in the site that may prove 
>>> useful:
>>>
>>>  
>>> http://people.apache.org/~bayard/commons-lang3-3.0-RC3/site/lang2-lang3-clirr--report.html
>>>
>>> This vote will close no sooner than in 72 hours time, 0700 GMT 2-May 2011.
>>>
>>> 
>>>   [ ] +1
>>>   [ ] -1, with reason
>>> 
>>>
>>> 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: FormattableUtils

[Stephen Colebourne]

On 4 May 2011 13:47, Matt Benson  wrote:
> At some point Hen mentioned the idea of a PairFormat class.  I don't
> think this is a bad idea, but the parsing capabilities of such a beast
> would be minimal to nonexistent, and it still doesn't seem that it
> would be configurable in a simple way without doing the equivalent of
> String.format("", left, right).  At this point I am still not sure
> what is the right mechanism for providing custom string
> representations of Pair in the simplest and most elegant possible way.
>  Have any ideas?

Not really.

toString(format) does the job of custom formatting pretty well.
Anything else is a wrapper around that which feels pretty unecessary.

Thus, I'd like to make Pair no longer implement Formattable (BTW, I
don't think anything in the JDK implements Formattable, so its a weird
interface).

Stephen

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

Re: FormattableUtils

[Matt Benson]

On Wed, May 4, 2011 at 6:24 AM, Stephen Colebourne  wrote:
> So
>
> While I can see the benefits of toString(String format), I'm
> struggling to understand what formatTo(...) gains Pair.
>
> I've added a test (in svn), and removed the Formattable interface from
> Pair (not in svn), and get the same output, so implementing
> Formattable appears to be pointless to me.
>

:)  If you follow the original trail of discussion, it seems to have
been a misunderstanding on my part.  We were discussing the propriety
vs. brittleness, etc., of the String toString(String format) method on
Pair and Hen mentioned Formattable.  I didn't see how that could be
used to accomplish the same thing, but in my respect for Hen I simply
assumed I wasn't understanding him and reinterpreted the statement
until I came to an interpretation that I could comprehend:  that we
use the Formattable part of the formatter APIs, and, necessarily,
subclassing, to specialize the output of a Pair.  After the fact Hen
stated this wasn't what he meant.  I'm still not sure exactly what he
did mean, but I didn't press the issue.  Gary felt strongly about not
needing to subclass (understandably) and restored toString(String).
At some point Hen mentioned the idea of a PairFormat class.  I don't
think this is a bad idea, but the parsing capabilities of such a beast
would be minimal to nonexistent, and it still doesn't seem that it
would be configurable in a simple way without doing the equivalent of
String.format("", left, right).  At this point I am still not sure
what is the right mechanism for providing custom string
representations of Pair in the simplest and most elegant possible way.
 Have any ideas?

> I am happy to retain FormattableUItils.

Yes, I am satisfied that it does its job regardless of the Pair debate.

Matt
>
> (needs to be decided pre release)
>
> Stephen
>
>
>
>
> On 25 April 2011 21:40, Matt Benson  wrote:
>> On Mon, Apr 25, 2011 at 8:39 AM, Matt Benson  wrote:
>>> On Mon, Apr 25, 2011 at 2:17 AM, Henri Yandell  wrote:
 On Fri, Apr 22, 2011 at 11:32 PM, Henri Yandell  wrote:
> On Fri, Apr 22, 2011 at 8:58 AM, Gary Gregory  
> wrote:
>> On Fri, Apr 22, 2011 at 9:58 AM, Matt Benson  
>> wrote:
>>
>>> On Fri, Apr 22, 2011 at 8:56 AM, Gary Gregory 
>>> wrote:
>>> > Hi All:
>>> >
>>> > Now that we have the shiny and new FormattableUtils class, what are 
>>> > the
>>> > other opportunities in [lang] to eat our own dog food?
>>> >
>>>
>>> What did you have in mind?
>>>
>>
>> I am just wondering what other [lang] classes should be Formattable.
>> StopWatch for example?
>
> Having hijacked the thread; possible Formattables that jump out:
>
> Fraction
> Range
> StopWatch
> The Mutables (or maybe Formatter knows special things about Number 
> already)
> BitField

 So I think the full potential list is the above plus StrBuilder,
 CharSet and JavaVersion.

 I'm not sure if it makes sense for each; but those are our current
 custom business objects.

 I'm scratching my head over Pair a bit though. What benefit did we add
 by implementing Formattable? My off-hand comment was hoping we would
 replace Gary's need to have his own subclass just to change the
 format, but he still needs that.

>>>
>>> I don't know of any way to use the Formattable interface to accomplish
>>> what you suggest, hence my initial confused comment.  Having gone back
>>> to reread the Javadoc examples, I concluded your intent was that if we
>>> were going to provide custom interactivity with the formatter APIs we
>>> should do it in a way conforming to the design of those classes.  The
>>> current example does this, but--you are correct--returns us to the
>>> state of affairs wherein a subclass is needed to customize an object's
>>> format.
>>>
 I'm also not sure of the benefit of FormattableUtils.append. We pass a
 CharSequence in and do much what the JDK would do on the toString?
>>>
>>> If you look at the Formattable API and example implementation in the
>>> class javadoc, the takeaway is that every Formattable implementation
>>> must handle width (number of characters to fill), precision (maximum
>>> width of meaningful data), and justification (provided simply as
>>> pad-left or, by exclusion, -right).  It was my feeling that 95% of
>>> implementations would therefore embed redundant code, with the main
>>> potential for divergence (due to their being unspecified by the
>>> interface) being the pad character used, and the form taken by the
>>> "ellipsis" when the meaningful output overflows the specified
>>> precision.  For this reason I extracted FormattableUtils.append to
>>> handle what I saw as the redundant part of implementing Formattable.
>>> This strikes me as a perfect fit for [lang].  Note that the way in
>>> which I am *least* satisfies with this method's implementation is
>>> that, like

Re: [VOTE] [LANG] Release Commons Lang 3.0 (based on RC3)

[Matt Benson]

On Wed, May 4, 2011 at 5:39 AM, Stephen Colebourne  wrote:
> (review now back from holiday)
>
> -1
[SNIP]
> I'm still looking for ImmutablePair to be final too, but perhaps I
> missed the conclusion of that debate... (NOT DONE in SVN)
>

Gary, now that you have toString(format) back, can you function with this?

Matt

> I also made some minor javadoc changes.
>
> Stephen
>
>
>
> On 29 April 2011 07:47, Henri Yandell  wrote:
>> Lang is ready to consider 3.0 release again.
>>
>> RC3 is available here:
>>
>>  http://people.apache.org/~bayard/commons-lang3-3.0-RC3/
>>
>> Maven artifacts:
>>
>>  http://people.apache.org/~bayard/commons-lang3-3.0-RC3/maven/
>>
>> Website:
>>
>>  http://people.apache.org/~bayard/commons-lang3-3.0-RC3/site/
>>
>> Note that there is a 2.6->3.0 Clirr report in the site that may prove useful:
>>
>>  http://people.apache.org/~bayard/commons-lang3-3.0-RC3/site/lang2-lang3-clirr--report.html
>>
>> This vote will close no sooner than in 72 hours time, 0700 GMT 2-May 2011.
>>
>> 
>>   [ ] +1
>>   [ ] -1, with reason
>> 
>>
>> 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: svn commit: r1099416 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/text/FormattableUtils.java

[Stephen Colebourne]

On 4 May 2011 13:10, sebb  wrote:
>>     /**
>> -     * {@link FormattableUtils} instances should NOT be constructed in
>> +     * {@code FormattableUtils} instances should NOT be constructed in
>
> What's wrong with @link here?

In general, it is not advisable to use @link in the first sentence of
a Javadoc class or method description. That is because it appears
linked in the summary documentation:

http://people.apache.org/~bayard/commons-lang3-3.0-RC3/site/apidocs/org/apache/commons/lang3/text/package-summary.html
http://people.apache.org/~bayard/commons-lang3-3.0-RC3/site/apidocs/org/apache/commons/lang3/text/FormattableUtils.html

These links (especially at the class level) are distracting when
viewing that summary.

Thus, it is better to use @code in the first sentence, and @link for
the main description if necessary (but only for the first link in any
doc). More generally, I would say that @link is a slightly over-used,
as there is frequently a link available via a method signature anyway
(not relevant in this case).

I'd also note that Oracle has recently had a mail recommending that
null, true and false are NOT surrounded by @code (for readbility).

Stephen

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

Re: svn commit: r1099416 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/text/FormattableUtils.java

[sebb]

On 4 May 2011 12:22,   wrote:
> Author: scolebourne
> Date: Wed May  4 11:22:29 2011
> New Revision: 1099416
>
> URL: http://svn.apache.org/viewvc?rev=1099416&view=rev
> Log:
> Javadoc
>
> Modified:
>    
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/text/FormattableUtils.java
>
> Modified: 
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/text/FormattableUtils.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/text/FormattableUtils.java?rev=1099416&r1=1099415&r2=1099416&view=diff
> ==
> --- 
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/text/FormattableUtils.java
>  (original)
> +++ 
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/text/FormattableUtils.java
>  Wed May  4 11:22:29 2011
> @@ -26,17 +26,24 @@ import org.apache.commons.lang3.StringUt
>  import org.apache.commons.lang3.Validate;
>
>  /**
> - * Provides utilities for working with {@link Formattable}s.
> + * Provides utilities for working with the {@code Formattable} 
> interface.
> + *
> + * The {@link Formattable} interface provides basic control over 
> formatting
> + * when using a {@code Formatter}. It is primarily concerned with numeric 
> precision
> + * and padding, and is not designed to allow generalised alternate 
> formats.
>  *
>  * @since Lang 3.0
>  * @version $Id$
>  */
>  public class FormattableUtils {
>
> +    /**
> +     * A format that simply outputs the value as a string.
> +     */
>     private static final String SIMPLEST_FORMAT = "%s";
>
>     /**
> -     * {@link FormattableUtils} instances should NOT be constructed in
> +     * {@code FormattableUtils} instances should NOT be constructed in

What's wrong with @link here?

>      * standard programming. Instead, the methods of the class should be 
> invoked
>      * statically.
>      *
> @@ -47,28 +54,29 @@ public class FormattableUtils {
>         super();
>     }
>
> +    //---
>     /**
>      * Get the default formatted representation of the specified
> -     * {@link Formattable}.
> +     * {@code Formattable}.

Ditto

>      *
> -     * @param formattable to convert to a String
> -     * @return String
> +     * @param formattable  the instance to convert to a string, not null
> +     * @return the resulting string, not null
>      */
>     public static String toString(Formattable formattable) {
>         return String.format(SIMPLEST_FORMAT, formattable);
>     }
>
>     /**
> -     * Handles the common {@link Formattable} operations of 
> truncate-pad-append,
> +     * Handles the common {@code Formattable} operations of 
> truncate-pad-append,
>      * with no ellipsis on precision overflow, and padding width underflow 
> with
>      * spaces.
>      *
> -     * @param seq to handle
> -     * @param formatter destination
> -     * @param flags for formatting
> -     * @param width of output
> -     * @param precision of output
> -     * @return {@code formatter}
> +     * @param seq  the string to handle, not null
> +     * @param formatter  the destination formatter, not null
> +     * @param flags  the flags for formatting, see {@code Formattable}
> +     * @param width  the width of the output, see {@code Formattable}
> +     * @param precision  the precision of the output, see {@code Formattable}
> +     * @return the {@code formatter} instance, not null
>      */
>     public static Formatter append(CharSequence seq, Formatter formatter, int 
> flags, int width,
>             int precision) {
> @@ -79,13 +87,13 @@ public class FormattableUtils {
>      * Handles the common {@link Formattable} operations of 
> truncate-pad-append,
>      * with no ellipsis on precision overflow.
>      *
> -     * @param seq to handle
> -     * @param formatter destination
> -     * @param flags for formatting
> -     * @param width of output
> -     * @param precision of output
> -     * @param padChar to use
> -     * @return {@code formatter}
> +     * @param seq  the string to handle, not null
> +     * @param formatter  the destination formatter, not null
> +     * @param flags  the flags for formatting, see {@code Formattable}
> +     * @param width  the width of the output, see {@code Formattable}
> +     * @param precision  the precision of the output, see {@code Formattable}
> +     * @param padChar  the pad character to use
> +     * @return the {@code formatter} instance, not null
>      */
>     public static Formatter append(CharSequence seq, Formatter formatter, int 
> flags, int width,
>             int precision, char padChar) {
> @@ -96,14 +104,14 @@ public class FormattableUtils {
>      * Handles the common {@link Formattable} operations of 
> truncate-pad-append,
>      * padding width underflow with spaces.
>      *
> -     * @param seq to handle
> -     * @param formatter d

Re: FormattableUtils

[Stephen Colebourne]

So

While I can see the benefits of toString(String format), I'm
struggling to understand what formatTo(...) gains Pair.

I've added a test (in svn), and removed the Formattable interface from
Pair (not in svn), and get the same output, so implementing
Formattable appears to be pointless to me.

I am happy to retain FormattableUItils.

(needs to be decided pre release)

Stephen




On 25 April 2011 21:40, Matt Benson  wrote:
> On Mon, Apr 25, 2011 at 8:39 AM, Matt Benson  wrote:
>> On Mon, Apr 25, 2011 at 2:17 AM, Henri Yandell  wrote:
>>> On Fri, Apr 22, 2011 at 11:32 PM, Henri Yandell  wrote:
 On Fri, Apr 22, 2011 at 8:58 AM, Gary Gregory  
 wrote:
> On Fri, Apr 22, 2011 at 9:58 AM, Matt Benson  wrote:
>
>> On Fri, Apr 22, 2011 at 8:56 AM, Gary Gregory 
>> wrote:
>> > Hi All:
>> >
>> > Now that we have the shiny and new FormattableUtils class, what are the
>> > other opportunities in [lang] to eat our own dog food?
>> >
>>
>> What did you have in mind?
>>
>
> I am just wondering what other [lang] classes should be Formattable.
> StopWatch for example?

 Having hijacked the thread; possible Formattables that jump out:

 Fraction
 Range
 StopWatch
 The Mutables (or maybe Formatter knows special things about Number already)
 BitField
>>>
>>> So I think the full potential list is the above plus StrBuilder,
>>> CharSet and JavaVersion.
>>>
>>> I'm not sure if it makes sense for each; but those are our current
>>> custom business objects.
>>>
>>> I'm scratching my head over Pair a bit though. What benefit did we add
>>> by implementing Formattable? My off-hand comment was hoping we would
>>> replace Gary's need to have his own subclass just to change the
>>> format, but he still needs that.
>>>
>>
>> I don't know of any way to use the Formattable interface to accomplish
>> what you suggest, hence my initial confused comment.  Having gone back
>> to reread the Javadoc examples, I concluded your intent was that if we
>> were going to provide custom interactivity with the formatter APIs we
>> should do it in a way conforming to the design of those classes.  The
>> current example does this, but--you are correct--returns us to the
>> state of affairs wherein a subclass is needed to customize an object's
>> format.
>>
>>> I'm also not sure of the benefit of FormattableUtils.append. We pass a
>>> CharSequence in and do much what the JDK would do on the toString?
>>
>> If you look at the Formattable API and example implementation in the
>> class javadoc, the takeaway is that every Formattable implementation
>> must handle width (number of characters to fill), precision (maximum
>> width of meaningful data), and justification (provided simply as
>> pad-left or, by exclusion, -right).  It was my feeling that 95% of
>> implementations would therefore embed redundant code, with the main
>> potential for divergence (due to their being unspecified by the
>> interface) being the pad character used, and the form taken by the
>> "ellipsis" when the meaningful output overflows the specified
>> precision.  For this reason I extracted FormattableUtils.append to
>> handle what I saw as the redundant part of implementing Formattable.
>> This strikes me as a perfect fit for [lang].  Note that the way in
>> which I am *least* satisfies with this method's implementation is
>> that, like the example in Formattable's javadoc,
>> Formatter.format(CharSequence) is called as part of the
>> implementation.  I would have preferred the implementation to write
>> directly to the Formatter's Appender; however I could find no
>> specification as to how to handle any theoretically encountered
>> IOExceptions, which are somehow swallowed by Formatter.format().  I
>> therefore opted for consistency by virtue of dropping back into the
>> formatter APIs as suggested by the designers (I personally think this
>> is a somewhat flawed design at least in this respect).
>>
>>>
>>> It almost feels that we need to add our own Formattable interface, but
>>> instead of formatTo we would have toString(String format). That's a
>>> weak API though. Users can't dictate whether the left or right comes
>>> first for the Pair example, they're stuck with left then right. The
>>> 'better' solution is to have a PairFormat class that has its own
>>> custom pattern language (%L and %R etc).
>>
>> It does seem as though the old Format APIs might be more appropriate
>> to custom formatting.  My hesitation there is that most often you're
>> going to encounter the situation where you're providing a
>> self-consciously incomplete implementation because what you can
>> format, you can't necessarily parse.
>>
>>>
>>> What am I missing?
>>>
>>> Currently I feel that we can dump FormattableUtils
>>
>> I hope I've explained why I feel #append is useful.  Further, if you
>> agree with the idea that it would be predictable for a Formattable to
>> use its own basic format as its to

Re: [VOTE] [LANG] Release Commons Lang 3.0 (based on RC3)

[sebb]

On 4 May 2011 12:11, sebb  wrote:
> On 29 April 2011 07:47, Henri Yandell  wrote:
>> Lang is ready to consider 3.0 release again.
>>
>> RC3 is available here:
>>
>>  http://people.apache.org/~bayard/commons-lang3-3.0-RC3/
>>
>> Maven artifacts:
>>
>>  http://people.apache.org/~bayard/commons-lang3-3.0-RC3/maven/
>>
>> Website:
>>
>>  http://people.apache.org/~bayard/commons-lang3-3.0-RC3/site/
>>
>> Note that there is a 2.6->3.0 Clirr report in the site that may prove useful:
>>
>>  http://people.apache.org/~bayard/commons-lang3-3.0-RC3/site/lang2-lang3-clirr--report.html
>>
>> This vote will close no sooner than in 72 hours time, 0700 GMT 2-May 2011.
>
> -1.
>
> I think the method (new to 3.0)
>
> FormatCache.getDateTimeInstance(Integer dateStyle, Integer timeStyle,
> TimeZone timeZone, Locale locale)
>
> should be changed to use ints, as all the existing callers use ints.
>
> Furthermore, the parameters have to be unboxed in order to pass them
> to DateFormat, so the boxing/unboxing is unnecessary and wasteful.
>

Also, I'm not entirely happy with the boxing that is often needed to
create a Range of int or long, e.g. in StringEscapeUtils.

Seems to me these are special cases that should be handled within
Range - or perhaps by special classes that could be more efficient by
avoiding the boxing and unboxing altogether.

>>
>> 
>>   [ ] +1
>>   [ ] -1, with reason
>> 
>>
>> 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

Re: [VOTE] [LANG] Release Commons Lang 3.0 (based on RC3)

[sebb]

On 29 April 2011 07:47, Henri Yandell  wrote:
> Lang is ready to consider 3.0 release again.
>
> RC3 is available here:
>
>  http://people.apache.org/~bayard/commons-lang3-3.0-RC3/
>
> Maven artifacts:
>
>  http://people.apache.org/~bayard/commons-lang3-3.0-RC3/maven/
>
> Website:
>
>  http://people.apache.org/~bayard/commons-lang3-3.0-RC3/site/
>
> Note that there is a 2.6->3.0 Clirr report in the site that may prove useful:
>
>  http://people.apache.org/~bayard/commons-lang3-3.0-RC3/site/lang2-lang3-clirr--report.html
>
> This vote will close no sooner than in 72 hours time, 0700 GMT 2-May 2011.

-1.

I think the method (new to 3.0)

FormatCache.getDateTimeInstance(Integer dateStyle, Integer timeStyle,
TimeZone timeZone, Locale locale)

should be changed to use ints, as all the existing callers use ints.

Furthermore, the parameters have to be unboxed in order to pass them
to DateFormat, so the boxing/unboxing is unnecessary and wasteful.

>
> 
>   [ ] +1
>   [ ] -1, with reason
> 
>
> 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

Re: Fileuplaoding issue

[sebb]

On 4 May 2011 11:48, karnakar t  wrote:
> Hi,
>
>
>
> I am using Tomhawk 2.0 for JSF 2.0 for file uploading.

Please subscribe to the Commons User list and ask there.

Also, please do not attach files (they are often stripped).
Save them somewhere public (e.g. pastebin) and include a link.

And do not send multiple posts about the same issue (perhaps that was
a mistake).

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

Re: commons file uploading error with tomhawk component

[sebb]

On 4 May 2011 11:42, karnakar t  wrote:
> Hi,
>
>
>
> I am using Tomhawk 2.0 for JSF 2.0 for file uploading.
>
>
>
> Am able to upload video ,image files(all types of files other than audio
> files)
>
>
>
> But am not able to upload some files like mp3 and some other audio files.

Please subscribe to the Commons User list and ask there.

Also, please do not attach files (they are often stripped).
Save them somewhere public (e.g. pastebin) and include a link.

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

Fileuplaoding issue

[karnakar t]

Hi,



I am using Tomhawk 2.0 for JSF 2.0 for file uploading.



Am able to upload video ,image files(all types of files other than audio
files)



But am not able to upload some files like mp3 and some other audio files.



Let me know Tomhawk or apache-commo- file upload support all type of mime
types?



Is there any bug with the libraries?



Am getting following exception while uploading .asx files or mp3 file





Exception while uploading file.

*org.apache.commons.fileupload.FileUploadBase$IOFileUploadException*:
Processing of multipart/form-data request failed.
\temp\upload__d900daf_12fba8f7378__8000_0011.tmp (The system cannot find
the path specified)

  at org.apache.commons.fileupload.FileUploadBase.parseRequest(*
FileUploadBase.java:371*)

  at
org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(*
ServletFileUpload.java:126*)

  at
org.apache.myfaces.webapp.filter.MultipartRequestWrapper.parseRequest(*
MultipartRequestWrapper.java:136*)

  at
org.apache.myfaces.webapp.filter.MultipartRequestWrapper.getParameter(*
MultipartRequestWrapper.java:274*)

  at com.sun.faces.context.RequestParameterMap.get(*
RequestParameterMap.java:71*)

  at com.sun.faces.context.RequestParameterMap.get(*
RequestParameterMap.java:52*)

  at java.util.Collections$UnmodifiableMap.get(*Collections.java:1282*)

  at
com.sun.faces.application.view.MultiViewHandler.calculateRenderKitId(*
MultiViewHandler.java:216*)

  at javax.faces.application.ViewHandlerWrapper.calculateRenderKitId(*
ViewHandlerWrapper.java:136*)

  at com.sun.faces.context.FacesContextImpl.isPostback(*
FacesContextImpl.java:206*)

  at com.sun.faces.lifecycle.RestoreViewPhase.execute(*
RestoreViewPhase.java:178*)

  at com.sun.faces.lifecycle.Phase.doPhase(*Phase.java:97*)

  at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(*
RestoreViewPhase.java:107*)

  at com.sun.faces.lifecycle.LifecycleImpl.execute(*
LifecycleImpl.java:114*)

  at javax.faces.webapp.FacesServlet.service(*FacesServlet.java:308*)

  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(*
ApplicationFilterChain.java:290*)

  at org.apache.catalina.core.ApplicationFilterChain.doFilter(*
ApplicationFilterChain.java:206*)

  at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(*
ExtensionsFilter.java:286*)

  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(*
ApplicationFilterChain.java:235*)

  at org.apache.catalina.core.ApplicationFilterChain.doFilter(*
ApplicationFilterChain.java:206*)

  at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(*
ExtensionsFilter.java:349*)

  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(*
ApplicationFilterChain.java:235*)

  at org.apache.catalina.core.ApplicationFilterChain.doFilter(*
ApplicationFilterChain.java:206*)

  at org.apache.catalina.core.StandardWrapperValve.invoke(*
StandardWrapperValve.java:233*)

  at org.apache.catalina.core.StandardContextValve.invoke(*
StandardContextValve.java:191*)

  at org.apache.catalina.core.StandardHostValve.invoke(*
StandardHostValve.java:127*)

  at org.apache.catalina.valves.ErrorReportValve.invoke(*
ErrorReportValve.java:102*)

  at org.apache.catalina.core.StandardEngineValve.invoke(*
StandardEngineValve.java:109*)

  at org.apache.catalina.connector.CoyoteAdapter.service(*
CoyoteAdapter.java:298*)

  at org.apache.coyote.http11.Http11Processor.process(*
Http11Processor.java:859*)

  at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(*
Http11Protocol.java:588*)

  at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(*
JIoEndpoint.java:489*)

  at java.lang.Thread.run(*Thread.java:619*)

Caused by: *java.io.FileNotFoundException*:
\temp\upload__d900daf_12fba8f7378__8000_0011.tmp (The system cannot find
the path specified)

  at java.io.FileOutputStream.open(*Native Method*)

  at java.io.FileOutputStream.(*FileOutputStream.java:179*)

  at java.io.FileOutputStream.(*FileOutputStream.java:131*)

  at
org.apache.commons.io.output.DeferredFileOutputStream.thresholdReached(*
DeferredFileOutputStream.java:123*)

  at
org.apache.commons.io.output.ThresholdingOutputStream.checkThreshold(*
ThresholdingOutputStream.java:220*)

  at org.apache.commons.io.output.ThresholdingOutputStream.write(*
ThresholdingOutputStream.java:127*)

  at org.apache.commons.fileupload.util.Streams.copy(*Streams.java:103*)

  at org.apache.commons.fileupload.util.Streams.copy(*Streams.java:66*)





*Warm Regards,*

* *

*Karnakar Goud Thallapalli
*Senior Engineer

*Virtusa (India) Pvt Ltd.*

Sy No.115, Nanakramguda Village, Serilingampally Mandal,

Ranga Reddy District, Hyderabad - 19, AP India

*Phone:  *+91 40 44528000 *Ext:  63207*

[image: cid:image011.jpg@01CB08A4.F95CFA30]  [image:
cid:image012.gif@01CB08A4.F95CFA30] 

Re: [VOTE] [LANG] Release Commons Lang 3.0 (based on RC3)

[sebb]

On 4 May 2011 06:01, Gary Gregory  wrote:
> On Tue, May 3, 2011 at 11:36 PM, sebb  wrote:
>
>> On 4 May 2011 03:42, Gary Gregory  wrote:
>> > Now that I've can see my monitor clearly (no more fever!), I understand
>> why
>> > this did not work.
>> >
>> > Running a standard test build for [lang] as documented on the Wiki using:
>> >
>> > mvn clean deploy -Prelease -Ptest-deploy
>> >
>> > does not produce a test jar. It does so for [codec] because this is in
>> the
>> > POM:
>> >
>> >      
>> >        org.apache.maven.plugins
>> >        maven-jar-plugin
>> >        
>> >          
>> >            
>> >              test-jar
>> >            
>> >          
>> >        
>> >      
>> >
>> > But in common-parent, the crucial executions element is only in the
>> > "apache-release" profile.
>> >
>> > This was what we agreed upon a couple of weeks ago but it I did not
>> > understand the Maven magic enough to see what that meant.
>> >
>> > My goal is to generate the test jar for all commons releases, which will
>> not
>> > happen since no one uses this "apache-release" profile.
>> >
>> > My questions then are:
>> >
>> > (1) Are there objections to include the Maven magic in the right place to
>> > generate a test jar?
>> > (2) What is the point of the apache-release profile?
>>
>> http://maven.apache.org/asf-pom/#The_apache-release_Profile
>>
>> This was introduced in version 6 (according to the POM comments);
>> commons parent 13 was the first to include Apache POM 6+ (in fact 7).
>>
>> Commons Parent has included a "release" profile since version 1.
>>
>> AIUI this is has much the same purpose as the "apache-release" profile
>> so at some point we could switch to using that.
>>
>
> When I run:
>
> mvn clean deploy -Papache-release -Ptest-deploy
>
> the build hangs in maven-gpg-plugin
>
> ugh...
>
> My set up:
>
> Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
> Maven home: C:\Java\apache-maven-3.0.3\bin\..
> Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_24\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"

What gpg version do you use?

Does "mvn package gpg:sign" work?

> Gary
>
>>
>> Try using that goal and see.
>>
>> > Thank you,
>> > Gary
>> >
>> > On Fri, Apr 29, 2011 at 4:56 PM, Henri Yandell 
>> wrote:
>> >
>> >> Not a clue. One didn't get created.
>> >>
>> >> Hen
>> >>
>> >> On Fri, Apr 29, 2011 at 10:15 AM, Gary Gregory 
>> >> wrote:
>> >> > Hi Hen,
>> >> >
>> >> > I was expecting to see a test jar in the deliverables, which is one of
>> >> the
>> >> > things commons-parent 21 brings to the table.
>> >> >
>> >> > What am I missing?
>> >> >
>> >> > Gary
>> >> >
>> >> > On Fri, Apr 29, 2011 at 2:47 AM, Henri Yandell 
>> >> wrote:
>> >> >
>> >> >> Lang is ready to consider 3.0 release again.
>> >> >>
>> >> >> RC3 is available here:
>> >> >>
>> >> >>  http://people.apache.org/~bayard/commons-lang3-3.0-RC3/
>> >> >>
>> >> >> Maven artifacts:
>> >> >>
>> >> >>  http://people.apache.org/~bayard/commons-lang3-3.0-RC3/maven/
>> >> >>
>> >> >> Website:
>> >> >>
>> >> >>  http://people.apache.org/~bayard/commons-lang3-3.0-RC3/site/
>> >> >>
>> >> >> Note that there is a 2.6->3.0 Clirr report in the site that may prove
>> >> >> useful:
>> >> >>
>> >> >>
>> >> >>
>> >>
>> http://people.apache.org/~bayard/commons-lang3-3.0-RC3/site/lang2-lang3-clirr--report.html
>> >> >>
>> >> >> This vote will close no sooner than in 72 hours time, 0700 GMT 2-May
>> >> 2011.
>> >> >>
>> >> >> 
>> >> >>   [ ] +1
>> >> >>   [ ] -1, with reason
>> >> >> 
>> >> >>
>> >> >> Hen
>> >> >>
>> >> >> -
>> >> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >> >> For additional commands, e-mail: dev-h...@commons.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > Thank you,
>> >> > Gary
>> >> >
>> >> > http://garygregory.wordpress.com/
>> >> > http://garygregory.com/
>> >> > http://people.apache.org/~ggregory/
>> >> > http://twitter.com/GaryGregory
>> >> >
>> >>
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >> For additional commands, e-mail: dev-h...@commons.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > 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
>>
>>
>
>
> --
> Thank you,
> Gary
>
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>

commons file uploading error with tomhawk component

[karnakar t]

Hi,



I am using Tomhawk 2.0 for JSF 2.0 for file uploading.



Am able to upload video ,image files(all types of files other than audio
files)



But am not able to upload some files like mp3 and some other audio files.



Let me know Tomhawk or apache-commo- file upload support all type of mime
types?



Is there any bug with the libraries?



Am getting following exception while uploading .asx files or mp3 file





Exception while uploading file.

*org.apache.commons.fileupload.FileUploadBase$IOFileUploadException*:
Processing of multipart/form-data request failed.
\temp\upload__d900daf_12fba8f7378__8000_0011.tmp (The system cannot find
the path specified)

  at org.apache.commons.fileupload.FileUploadBase.parseRequest(*
FileUploadBase.java:371*)

  at
org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(*
ServletFileUpload.java:126*)

  at
org.apache.myfaces.webapp.filter.MultipartRequestWrapper.parseRequest(*
MultipartRequestWrapper.java:136*)

  at
org.apache.myfaces.webapp.filter.MultipartRequestWrapper.getParameter(*
MultipartRequestWrapper.java:274*)

  at com.sun.faces.context.RequestParameterMap.get(*
RequestParameterMap.java:71*)

  at com.sun.faces.context.RequestParameterMap.get(*
RequestParameterMap.java:52*)

  at java.util.Collections$UnmodifiableMap.get(*Collections.java:1282*)

  at
com.sun.faces.application.view.MultiViewHandler.calculateRenderKitId(*
MultiViewHandler.java:216*)

  at javax.faces.application.ViewHandlerWrapper.calculateRenderKitId(*
ViewHandlerWrapper.java:136*)

  at com.sun.faces.context.FacesContextImpl.isPostback(*
FacesContextImpl.java:206*)

  at com.sun.faces.lifecycle.RestoreViewPhase.execute(*
RestoreViewPhase.java:178*)

  at com.sun.faces.lifecycle.Phase.doPhase(*Phase.java:97*)

  at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(*
RestoreViewPhase.java:107*)

  at com.sun.faces.lifecycle.LifecycleImpl.execute(*
LifecycleImpl.java:114*)

  at javax.faces.webapp.FacesServlet.service(*FacesServlet.java:308*)

  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(*
ApplicationFilterChain.java:290*)

  at org.apache.catalina.core.ApplicationFilterChain.doFilter(*
ApplicationFilterChain.java:206*)

  at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(*
ExtensionsFilter.java:286*)

  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(*
ApplicationFilterChain.java:235*)

  at org.apache.catalina.core.ApplicationFilterChain.doFilter(*
ApplicationFilterChain.java:206*)

  at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(*
ExtensionsFilter.java:349*)

  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(*
ApplicationFilterChain.java:235*)

  at org.apache.catalina.core.ApplicationFilterChain.doFilter(*
ApplicationFilterChain.java:206*)

  at org.apache.catalina.core.StandardWrapperValve.invoke(*
StandardWrapperValve.java:233*)

  at org.apache.catalina.core.StandardContextValve.invoke(*
StandardContextValve.java:191*)

  at org.apache.catalina.core.StandardHostValve.invoke(*
StandardHostValve.java:127*)

  at org.apache.catalina.valves.ErrorReportValve.invoke(*
ErrorReportValve.java:102*)

  at org.apache.catalina.core.StandardEngineValve.invoke(*
StandardEngineValve.java:109*)

  at org.apache.catalina.connector.CoyoteAdapter.service(*
CoyoteAdapter.java:298*)

  at org.apache.coyote.http11.Http11Processor.process(*
Http11Processor.java:859*)

  at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(*
Http11Protocol.java:588*)

  at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(*
JIoEndpoint.java:489*)

  at java.lang.Thread.run(*Thread.java:619*)

Caused by: *java.io.FileNotFoundException*:
\temp\upload__d900daf_12fba8f7378__8000_0011.tmp (The system cannot find
the path specified)

  at java.io.FileOutputStream.open(*Native Method*)

  at java.io.FileOutputStream.(*FileOutputStream.java:179*)

  at java.io.FileOutputStream.(*FileOutputStream.java:131*)

  at
org.apache.commons.io.output.DeferredFileOutputStream.thresholdReached(*
DeferredFileOutputStream.java:123*)

  at
org.apache.commons.io.output.ThresholdingOutputStream.checkThreshold(*
ThresholdingOutputStream.java:220*)

  at org.apache.commons.io.output.ThresholdingOutputStream.write(*
ThresholdingOutputStream.java:127*)

  at org.apache.commons.fileupload.util.Streams.copy(*Streams.java:103*)

  at org.apache.commons.fileupload.util.Streams.copy(*Streams.java:66*)





*Warm Regards,*

* *

*Karnakar Goud Thallapalli
*Senior Engineer

*Virtusa (India) Pvt Ltd.*

Sy No.115, Nanakramguda Village, Serilingampally Mandal,

Ranga Reddy District, Hyderabad - 19, AP India

*Phone:  *+91 40 44528000 *Ext:  63207*

[image: cid:image011.jpg@01CB08A4.F95CFA30]  [image:
cid:image012.gif@01CB08A4.F95CFA30] 

Re: [VOTE] [LANG] Release Commons Lang 3.0 (based on RC3)

[Stephen Colebourne]

(review now back from holiday)

-1

I'm unhappy with the change in FastDateFormat from new
GregorianCalendar() to Calendar.getInstance(). This will pick up
alternate calendar systems based on the default locale, and probably
mess up the rest of the code which I expect relies on it being
gregorian.  (DONE in SVN)

I'm still looking for ImmutablePair to be final too, but perhaps I
missed the conclusion of that debate... (NOT DONE in SVN)

I also made some minor javadoc changes.

Stephen



On 29 April 2011 07:47, Henri Yandell  wrote:
> Lang is ready to consider 3.0 release again.
>
> RC3 is available here:
>
>  http://people.apache.org/~bayard/commons-lang3-3.0-RC3/
>
> Maven artifacts:
>
>  http://people.apache.org/~bayard/commons-lang3-3.0-RC3/maven/
>
> Website:
>
>  http://people.apache.org/~bayard/commons-lang3-3.0-RC3/site/
>
> Note that there is a 2.6->3.0 Clirr report in the site that may prove useful:
>
>  http://people.apache.org/~bayard/commons-lang3-3.0-RC3/site/lang2-lang3-clirr--report.html
>
> This vote will close no sooner than in 72 hours time, 0700 GMT 2-May 2011.
>
> 
>   [ ] +1
>   [ ] -1, with reason
> 
>
> 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