Re: [LANG] Towards 3.3

Nice discussion. Thanks for clearing this up. So Duncan: go ahead if you got the time. 2014/1/31 Duncan Jones > On 31 January 2014 04:37, Henri Yandell wrote: > > Read section 5 of the license. > > Ok, that's pretty clear-cut then. To save others from dragging up the > wording: > > "5. Submiss

Re: [LANG] Towards 3.3

On 31 January 2014 04:37, Henri Yandell wrote: > Read section 5 of the license. Ok, that's pretty clear-cut then. To save others from dragging up the wording: "5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Wor

Re: [LANG] Towards 3.3

Read section 5 of the license. On Jan 30, 2014 10:16 AM, "Benedikt Ritter" wrote: > I'm not sure whether providing a patch for an AL licensed file is > automatically licensed under AL as well. In the end the raw diff file does > not contain the AL header, so you're better of with an ICLA. > > Be

Re: svn commit: r1563014 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/reflect/MemberUtils.java

I had forgotten the class was package-scoped. Carry on :-) Matt On Jan 30, 2014 6:41 PM, "Gary Gregory" wrote: > On Thu, Jan 30, 2014 at 6:44 PM, Matt Benson wrote: > >> This change breaks binary compatibility. >> > > I think this is OK because the class is package private. Strictly speaking >

Re: [LANG] FieldUtils forceAccess does not force access for final

Looking at FieldUtils some more... setAccessible(true) is never rollback with a matching setAccessible(false). This is a non-trivial side effect. I am wondering whether this side effect should be perpetuated with removing final modifiers: - Should removeFinalModifier have balanced calls to setAc

Re: svn commit: r1563014 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/reflect/MemberUtils.java

On Thu, Jan 30, 2014 at 6:44 PM, Matt Benson wrote: > This change breaks binary compatibility. > I think this is OK because the class is package private. Strictly speaking it does break BC if a user's class is also in org/apache/commons/ lang3/reflect/ which I claim is asking for trouble. Why el

Re: svn commit: r1563014 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/reflect/MemberUtils.java

This change breaks binary compatibility. On Thu, Jan 30, 2014 at 5:28 PM, wrote: > Author: ggregory > Date: Thu Jan 30 23:28:26 2014 > New Revision: 1563014 > > URL: http://svn.apache.org/r1563014 > Log: > [LANG-961] > org.apache.commons.lang3.reflect.FieldUtils.removeFinalModifier(Field) does

Re: svn commit: r1562992 - in /commons/proper/dbcp/branches/DBCP_1_5_x_BRANCH/src: changes/changes.xml main/java/org/apache/commons/dbcp/datasources/InstanceKeyObjectFactory.java test/java/org/apache/

On 30 January 2014 21:54, wrote: > Author: markt > Date: Thu Jan 30 21:54:56 2014 > New Revision: 1562992 > > URL: http://svn.apache.org/r1562992 > Log: > Fix DBCP-369 > Fix threading issue when using multiple instances of the SharedPoolDataSource > concurrently. > I can't reproduce this but the

[continuum] BUILD FAILURE: Apache Commons DBCP - Apache Commons (Project Maven 2 Build Definition (Java 1.7))

Online report : https://continuum-ci.apache.org/continuum/buildResult.action?buildId=27933&projectId=73 Build statistics: State: Failed Previous State: Ok Started at: Thu 30 Jan 2014 22:21:55 + Finished at: Thu 30 Jan 2014 22:23:41 + Total time: 1m 45s Build Trigger: Schedule

Re: [math][MATH-749] Convex hull

On 01/27/2014 09:13 PM, Thomas Neidhart wrote: > On 01/27/2014 10:13 AM, Luc Maisonobe wrote: >> Le 26/01/2014 23:52, Thomas Neidhart a écrit : >>> Hi, >> >> Hi Thomas, >> >>> >>> finally, I have a patch ready to be included for MATH-749. >>> What took me so long was some confusion about the type s

[continuum] BUILD FAILURE: Apache Commons DBCP - Apache Commons ( Project Maven 2 Build Definition (Java 1.7) )

Online report : https://continuum-ci.apache.org/continuum/buildResult.action?buildId=27932&projectId=297 Build statistics: State: Failed Previous State: Ok Started at: Thu 30 Jan 2014 22:20:18 + Finished at: Thu 30 Jan 2014 22:21:51 + Total time: 1m 33s Build Trigger: Schedule

Re: [DBCP] Standardise Maven layout?

Also done for 1.5 branch However the test TestSharedPoolDataSource.testClosePool() is failing in both Ant and Maven. I don't think that's related to the source move. On 30 January 2014 21:28, sebb wrote: > On 30 January 2014 20:54, Mark Thomas wrote: >> On 30/01/2014 20:40, sebb wrote: >>> @M

Re: [DBCP] Standardise Maven layout?

On 30 January 2014 20:54, Mark Thomas wrote: > On 30/01/2014 20:40, sebb wrote: >> @Mark: I have done a local experiment, and compile/test works fine >> (not many changes needed to pom or build.xml) >> >> However the change will obviously affect concurrent activity. >> If you are agreeable to the

Re: [DBCP] Standardise Maven layout?

On 30/01/2014 20:40, sebb wrote: > @Mark: I have done a local experiment, and compile/test works fine > (not many changes needed to pom or build.xml) > > However the change will obviously affect concurrent activity. > If you are agreeable to the change, please can you let me know when > there is a

Re: [DBCP] Standardise Maven layout?

@Mark: I have done a local experiment, and compile/test works fine (not many changes needed to pom or build.xml) However the change will obviously affect concurrent activity. If you are agreeable to the change, please can you let me know when there is a window where you are temporarily done with c

Re: [DBCP] Standardise Maven layout?

Go for it! 2014/1/30 sebb > At present DBCP uses a non-standard Maven layout. > > For example src/java should really be src/main/java > > Generally the poms are easier to configure if the standard layout [1] is > used. > Commons Parent generally assumes the standard layout as does the Apache >

Re: [DBCP] Standardise Maven layout?

+1 Gary On Thu, Jan 30, 2014 at 1:56 PM, sebb wrote: > At present DBCP uses a non-standard Maven layout. > > For example src/java should really be src/main/java > > Generally the poms are easier to configure if the standard layout [1] is > used. > Commons Parent generally assumes the standard

[DBCP] Standardise Maven layout?

At present DBCP uses a non-standard Maven layout. For example src/java should really be src/main/java Generally the poms are easier to configure if the standard layout [1] is used. Commons Parent generally assumes the standard layout as does the Apache pom. OK if I fix this? [Obviously the Ant b

Re: [LANG] FieldUtils forceAccess does not force access for final

Yes. Another issue is that the way the code is currently factored means that you'd get write access when you only need read... Gary Original message From: Benedikt Ritter Date:01/30/2014 13:22 (GMT-05:00) To: Commons Developers List Subject: Re: [LANG] FieldUtils forceA

Re: [lang] RuntimeException types

On 30 Jan 2014 16:38, "Matt Benson" wrote: > > How do we feel about changing the type of a thrown RTE? Specifically, we > have agreed to standardize on the idea that Validate.notNull() throws > NullPointerException, but the recently added > FieldUtils#removeFinalModifier() method validates the in

Re: [LANG] FieldUtils forceAccess does not force access for final

So the point you're making is that accessibility alway includes write access? 2014/1/29 Gary Gregory > Hi All: > > I have a use case where I need to use reflection to set a public static > final Object. > > This does not work with our FieldUtils class because the "forceAccess" > argument is onl

[continuum] BUILD FAILURE: Apache Commons DBCP - Apache Commons (Project Maven 2 Build Definition (Java 1.7))

Online report : https://continuum-ci.apache.org/continuum/buildResult.action?buildId=27923&projectId=73 Build statistics: State: Failed Previous State: Ok Started at: Thu 30 Jan 2014 18:20:20 + Finished at: Thu 30 Jan 2014 18:21:35 + Total time: 1m 15s Build Trigger: Schedule

Re: [continuum] BUILD FAILURE: Apache Commons DBCP - Apache Commons (Project Maven 2 Build Definition (Java 1.7))

The problem is due to failing to load the Utils class; in turn this is because the resource LocalStrings.properties has not been copied to target/ by the build process. I think that's because the resource is in the wrong place for Maven to pick it up. I'll try and fix this soon. On 30 January 2

Re: [LANG] Towards 3.3

I'm not sure whether providing a patch for an AL licensed file is automatically licensed under AL as well. In the end the raw diff file does not contain the AL header, so you're better of with an ICLA. Benedikt 2014/1/27 Henri Yandell > Depends whose arguing probably :) > > Our license gives u

Re: [scxml] JAXB?

> On Thursday, January 30, 2014 9:40 AM, Gary Gregory > wrote: > > On Thu, Jan 30, 2014 at 9:24 AM, Woonsan Ko wrote: > >> AFAIK, SCXML allows ad hoc elements from arbitrary namespaces inside >> blocks of executable content (see section 4.10)  [1]. >> So, I guess JAXB couldn't work very

Re: [dbcp] v2 with pool2

On 1/30/14, 7:45 AM, Mark Thomas wrote: > On 30/01/2014 15:34, Gary Gregory wrote: >> On Thu, Jan 30, 2014 at 10:30 AM, Mark Thomas wrote: >> >>> On 30/01/2014 15:20, Gary Gregory wrote: Hi All: What is the outlook on getting a pool2-based dbcp2? >>> I'm working on that at the momen

[continuum] BUILD FAILURE: Apache Commons DBCP - Apache Commons (Project Maven 2 Build Definition (Java 1.7))

Online report : https://continuum-ci.apache.org/continuum/buildResult.action?buildId=27918&projectId=73 Build statistics: State: Failed Previous State: Failed Started at: Thu 30 Jan 2014 17:15:59 + Finished at: Thu 30 Jan 2014 17:17:13 + Total time: 1m 13s Build Trigger: Force

Re: [lang] RuntimeException types

Aside from that, the method continues the tradition of this class not cleaning up after itself. Please see my other email thread related to https://issues.apache.org/jira/browse/LANG-959. Gary On Thu, Jan 30, 2014 at 11:37 AM, Matt Benson wrote: > How do we feel about changing the type of a t

[lang] RuntimeException types

How do we feel about changing the type of a thrown RTE? Specifically, we have agreed to standardize on the idea that Validate.notNull() throws NullPointerException, but the recently added FieldUtils#removeFinalModifier() method validates the incoming field parameter with Validate.isTrue(field != n

Re: [dbcp] v2 with pool2

On Thu, Jan 30, 2014 at 10:45 AM, Mark Thomas wrote: > On 30/01/2014 15:34, Gary Gregory wrote: > > On Thu, Jan 30, 2014 at 10:30 AM, Mark Thomas wrote: > > > >> On 30/01/2014 15:20, Gary Gregory wrote: > >>> Hi All: > >>> > >>> What is the outlook on getting a pool2-based dbcp2? > >> > >> I'm w

Re: [dbcp] v2 with pool2

On 30/01/2014 15:34, Gary Gregory wrote: > On Thu, Jan 30, 2014 at 10:30 AM, Mark Thomas wrote: > >> On 30/01/2014 15:20, Gary Gregory wrote: >>> Hi All: >>> >>> What is the outlook on getting a pool2-based dbcp2? >> >> I'm working on that at the moment. There are currently 48 open bugs for >> DB

Re: [dbcp] v2 with pool2

On Thu, Jan 30, 2014 at 10:30 AM, Mark Thomas wrote: > On 30/01/2014 15:20, Gary Gregory wrote: > > Hi All: > > > > What is the outlook on getting a pool2-based dbcp2? > > I'm working on that at the moment. There are currently 48 open bugs for > DBCP, at least some of which will require API chang

Re: [dbcp] v2 with pool2

On 30/01/2014 15:20, Gary Gregory wrote: > Hi All: > > What is the outlook on getting a pool2-based dbcp2? I'm working on that at the moment. There are currently 48 open bugs for DBCP, at least some of which will require API changes to fix. I haven't yet formed an opinion on which ones to fix, wh

[dbcp] v2 with pool2

Hi All: What is the outlook on getting a pool2-based dbcp2? Thank you, Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition JUnit in Action, Second Edition Spring Batch in

[continuum] BUILD FAILURE: Apache Commons DBCP - Apache Commons (Project Maven 2 Build Definition (Java 1.7))

Online report : https://continuum-ci.apache.org/continuum/buildResult.action?buildId=27915&projectId=73 Build statistics: State: Failed Previous State: Failed Started at: Thu 30 Jan 2014 15:17:18 + Finished at: Thu 30 Jan 2014 15:18:30 + Total time: 1m 12s Build Trigger: Force

Re: [scxml] JAXB?

On Thu, Jan 30, 2014 at 9:24 AM, Woonsan Ko wrote: > AFAIK, SCXML allows ad hoc elements from arbitrary namespaces inside > blocks of executable content (see section 4.10) [1]. > So, I guess JAXB couldn't work very well or not really worth for in this > context? > Why not? JAXB is supposed to p

Re: [scxml] JAXB?

AFAIK, SCXML allows ad hoc elements from arbitrary namespaces inside blocks of executable content (see section 4.10) [1]. So, I guess JAXB couldn't work very well or not really worth for in this context? [1] http://www.w3.org/TR/scxml/ > On Wednesday, January 29, 2014 5:33 PM, Gary Gregory

[continuum] BUILD FAILURE: Apache Commons DBCP - Apache Commons (Project Maven 2 Build Definition (Java 1.7))

Online report : https://continuum-ci.apache.org/continuum/buildResult.action?buildId=27913&projectId=73 Build statistics: State: Failed Previous State: Ok Started at: Thu 30 Jan 2014 14:20:23 + Finished at: Thu 30 Jan 2014 14:21:52 + Total time: 1m 29s Build Trigger: Schedule