Re: [math] Preparing for v3.6.2 release

, 16 Sep 2019 at 20:08, Stephen Colebourne wrote: > > As far as I can tell, mvn site works on the branch with my PR. Shall I merge > it? > I wasn't planning on fixing master. > Stephen > > > On Mon, 16 Sep 2019 at 18:26, Gary Gregory wrote: > > > > Note that ri

Re: [math] Preparing for v3.6.2 release

lugin:3.0.0:check (validate) on > project commons-rng-parent: You have 10 Checkstyle violations. -> [Help 1] > > Can someone please fix those so we can run simple builds from the command > line? > > Gary > > > > On Mon, Sep 16, 2019 at 1:16 PM sebb wrote: >

[math] Preparing for v3.6.2 release

I've started to try and get a release out on the branch to get the Java module name in. Since I haven't committed in many years this isn't going to be easy. I've successfully pushed a small fix directly to the MATH_3_X branch. I've seen something suggesting that branches can't be deleted, which

Re: [math] MATH-1486 and release 3.6.2

On Fri, 7 Jun 2019 at 15:16, Gilles Sadowski wrote: > drive such a maintenance/security release. > If the build process works on your machine, you are a better > RM candidate. ;-) Given I haven't committed to commons for 10+ years (at a guess), I'm not a PMC member and probably don't have

Re: [math] MATH-1486 and release 3.6.2

On Thu, 6 Jun 2019 at 23:21, Gilles Sadowski wrote: > I was about to merge the PR but, on my machine, the build fails. > Did you try? `mvn clean verify` works for me (maven running on Java 7 and on Java 8). > Back then (pre-fork), I was in favour of maintaining both lines (3.X > and 4.X); but

[math] MATH-1486 and release 3.6.2

I've raised a GitHub PR [1] to add the Java 9 module name to [math] on the MATH_3_X branch. Assuming that is merged, I'm willing to raise another PR with the necessary bits to prepare the repo to release v3.6.2. This approach sidesteps all issues with commons-4 and does the minimum necessary for

Re: [commons-numbers] [...] NUMBERS-91: Added ofInt() factory methods [...]

I'd suggest `of` and `ofXxx` for factories that perform little work, such as assigning to instance fields, and `from` and `fromXxx` for factories that perform meaningful work or conversion. Stephen On Fri, 28 Dec 2018 at 17:24, Eric Barnhill wrote: > > Fractions are constructed using either

Re: [Numbers] Inheritance and ValJO ?

behaviour without subclass. Stephen On Wed, 12 Dec 2018 at 23:20, Gilles wrote: > Hi. > > On Wed, 12 Dec 2018 22:48:54 +, Stephen Colebourne wrote: > > I think this has already been worked out, but the main reason for no > > inheritance is that is probably blocks futur

Re: [Numbers] Inheritance and ValJO ? (Was: Where to define "quaternion"?)

I think this has already been worked out, but the main reason for no inheritance is that is probably blocks future conversion to value types. Composition instead of inheritance is usually the right solution. Stephen On Sun, 9 Dec 2018 at 10:21, Gilles wrote: > Hello. > > After the discussion

Re: [numbers] Making fractions VALJOs

As the author of the blog and term VALJO, here are some comments on Fraction: You should use `of()` (overloading allowed) when the factory normally succeeds. You should use `from` (overloading allowed) when the factory methods are performing a conversion and have a reasonable chance of failure.

Re: [Math] Beta release (Was: [All] What's in a "beta" release?)

What I would love to see it a release of commons-math 3 with an Automatic-Module-Name for Java 9 modules (potentially the only change). You could use the release as a way of advertising the progress towards v4. Stephen On Thu, 30 Aug 2018 at 19:16, Gilles wrote: > > On Thu, 30 Aug 2018

Re: Java 11 Compatibility check: Commons-beanutils, Commons-cli, Commons-codec, Commons-collections, Commons-csv, Commons-digester, Commons-discovery, Commons-fileupload, Commons-io, Commons-lang, Com

Spamming multiple open source projects with the same question is not appropriate behaviour for a company. Open source does not have "support". Its up to users to try the code, see if it works and report issues. Please cease and desist your spamming. Stephen On 17 August 2018 at 08:37, Dragan,

Re: [all] java release cycle predicament

generally been fine. Stephen On 10 July 2018 at 18:00, Rob Tompkins wrote: > > >> On Jul 10, 2018, at 12:53 PM, Stephen Colebourne >> wrote: >> >> Look at Joda-Convert/Joda-Parent for example. A Java 6 project that >> builds on Java 8 or later, and has a module-i

Re: [all] java release cycle predicament

Look at Joda-Convert/Joda-Parent for example. A Java 6 project that builds on Java 8 or later, and has a module-info.java. Cobertura just needs replacing with JaCoCo. FindBugs replaced by SpotBugs Lots of plugin versions updated. And lots of profiles, as per Joda-Convert/Joda-Parent Stephen

Re: [LANG] Java 9 problems because of dependencies to java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)

____From: Benedikt Ritter >>> >>> To: Commons Developers List >>> Sent: Monday, 5 June 2017 10:49 PM >>> Subject: [LANG] Java 9 problems because of dependencies to java.desktop >>> (Was: Re: [LANG] Thoughts about Lang 4.0)

Re: [LANG] Java 9 problems because of dependencies to java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)

On 10 June 2018 at 00:02, Bruno P. Kinoshita wrote: > Yes, that's my understanding. We would use require static on java.desktop, > but users wouldn't have any issues as long as they did not use the version of > the class that requires java.desktop. > > If the user want/needs to use those

Re: [all] Maven Build with Java 10/11?

Just to note that surefire v2.21.0 is out now. No idea if that helps. Stephen On 9 March 2018 at 08:22, Stefan Bodewig wrote: > Hi all > > I wanted to see whether anything was broken in COMPRESS with the Java10 > RC or the EA version of Java11 - unfortunately the build fails

Re: Prepare commons to JDK 9

On 7 March 2018 at 18:56, Ralph Goers wrote: > Actually, you really do need to use a multi-release jar to include a > module-info class file. Otherwise it may be sitting alongside of classes > compiled for an earlier java release and various tools will fail because

Re: Prepare commons to JDK 9

1) Moving to Java 9 as a base would be a terrible choice. Java 9 is a six-month release which is about to be replaced by Java 10, which will then be replaced by Java 11. Thus, Java 8 is the only sensible baseline right now. 2) Compiling a single jar file such that it works on Java 8 but has a

Re: [Numbers] Make "Complex" a "final" class? (Was: [...] API of "Complex")

Some of the classes you are talking about are what I call VALJOs. Follow these guidelines and your class will be well placed for the future. http://blog.joda.org/2014/03/valjos-value-java-objects.html Stephen On 2 February 2018 at 12:45, Gilles wrote: > On Thu, 1

Re: [Numbers] API of "Complex"

On 1 February 2018 at 15:30, Gary Gregory wrote: > For example, (picking a made up example) this reads really well to me: > Pair.of(foo, bar) because that what you'd use in spoken English. > > OTOH, this does not read well to me: Fraction.of(num, denum); this would be >

Re: Parent POM and automatic module name

This seems a lot more effort than just adding something to the pom.xml in the child project. Stephen On 9 January 2018 at 12:11, Gilles wrote: > Hi. > > My suggestion would be > "profile.java_automatic_module_name" > in the top directory. > > Gilles > > > On Mon,

Re: [beanutils] Toward 2.0.0

On 28 December 2017 at 19:49, Gary Gregory wrote: > Hi All, > > - BeanUtils now has a new package o.a.c.beanutils2. > - BeanUtils now depends on Apache Commons Collection 4 (instead of 3), > which caused the above. > > What more do we want before releasing 2.0.0? > >

Re: [dbcp] Releasing 2.2.0

Just to note that commons-pool v2.5.0 did not have Automatic-Module-Name added, which is sad. Stephen On 20 December 2017 at 17:31, Gary Gregory wrote: > Hi All, > > Now that Apache Commons Pool 2.5.0 and builds cleanly with Commons DBCP > master, I'd like to release

Re: [All] "Commons Math" is not a component

gil...@harfang.homelinux.org> wrote: > Hi all. > > Stephen Colebourne correctly summarized the situation[1]: > Project management must be based on life-cycle, not the > other way around. > > Here below, a concrete plan is proposed in answer to the > suggestion (of a fork) made by Martijn Ve

Re: [All][Math] New component: "Commons Geometry"?

Frankly, as an observer, this issue seems to be handled pretty poorly. Commons-Math is currently dead. There are people willing to put in effort to work on parts of it, but they are blocked at every turn. Various options are put forward, but nothing ever happens. In technical terms, if

Re: [lang] release 3.7

You'd need https://github.com/apache/commons-lang/pull/304 too for Java 9 Stephen On 3 November 2017 at 17:36, Gary Gregory wrote: > Hi All: > > I propose we release 3.7 principally to pick up > https://issues.apache.org/jira/browse/LANG-1365 to support those brave >

Re: [LOGGING] Logging is Java 1.2 but required Java 1.4 code

Does commons-logging need to be a full module with a module-info.java? Probably not at this point. Adding Automatic-Module-Name is probably sufficient. However, if someone wants to do the work, then adding module-info shouldn't be blocked IMO. I don't believe that module-info.java requires Java 6

Re: [VOTE] Release Apache Commons Pool 2.4.3 based on RC1

Just to note that there is no Automatic-Module-Name in the MANIFEST On 25 October 2017 at 04:19, Gary Gregory wrote: > We have fixed a few bugs since Apache Commons Pool 2.4.2 was released, so I > would like to release Apache Commons Pool 2.4.3. > > Apache Commons Pool 2.4.3

Re: [lang] Module Info

hecks. > > Thanks, > Pascal > > > Am 17.10.2017 um 20:08 schrieb Stephen Colebourne: >> >> See latest changes. >> >> https://github.com/apache/commons-lang/pull/299/files >> >> https://travis-ci.org/apache/commons-lang/builds/289148663 >

[lang] Module Info

See latest changes. https://github.com/apache/commons-lang/pull/299/files https://travis-ci.org/apache/commons-lang/builds/289148663 It now builds on Java 7, 8 and 9, varying what it does on each JDK. Releases will need to be on Java 9 for the jar file, but 8 for the site plugin if I

Re: [LANG] Add module-info.java?

On 16 October 2017 at 14:14, Simon Spero wrote: > [In regards to original question, -0.0 (harmless, but pointless, since > applications should not use lang as a jpms module. Huh? Of course they should. > To be usable as a jpms > module, EVERY release that has ANY api

Re: [LANG] Add module-info.java?

ling our there >>>> does not play well with Java 9 class files. >>>> >>>> The last time I tried to use Log4j 2 (which contains Java 9 classes files >>>> in the right multi-jar spot) with an Android app, the Android tooling >>> threw >>>>

Re: [LANG] Add module-info.java?

On 14 October 2017 at 14:05, Rob Tompkins wrote: >> On Oct 14, 2017, at 8:43 AM, Benedikt Ritter wrote: > Feels like a change that would warrant a major version change, but that would > have us maintaining another major version branch. No need for a

Re: [lang] Commons Lang 2.x release for Java 9

Looks good AFAICT Stephen On 9 October 2017 at 14:39, Emmanuel Bourg wrote: > Le 29/09/2017 à 10:08, Emmanuel Bourg a écrit : > >> I'd like to prepare a new release of Commons Lang 2 that addresses the >> Java 9 compatibility. I have two items in mind for this update, the >>

Re: [LOGGING] Release with Java 9 Module support

On 1 October 2017 at 11:34, Stefan Bodewig wrote: > - only add the automatic module name to commons-logging and release api > and adapter as they are. Exactly. This is the right approach. Stephen - To

Re: [LOGGING] Release with Java 9 Module support

On 27 September 2017 at 00:01, Emmanuel Bourg wrote: > I wonder if we should do the same for commons-lang 2.x, it's still > commonly used. Yes. This would be very helpful Stephen - To unsubscribe, e-mail:

Re: [LOGGING] Release with Java 9 Module support

. (In fact, why not just delete their creation in pom.xml ?) Stephen On 26 September 2017 at 22:05, Benedikt Ritter <brit...@apache.org> wrote: > >> Am 26.09.2017 um 22:54 schrieb Stephen Colebourne <scolebou...@joda.org>: >> >> On 26 September 2017 at 18:48, Jörg Schai

Re: [LOGGING] Release with Java 9 Module support

On 26 September 2017 at 18:48, Jörg Schaible wrote: > AFAICS we have only commons-logging. The other artifacts have not been part > of any release in the last decade. Simple then! Stephen - To

Re: [LOGGING] Release with Java 9 Module support

On 26 September 2017 at 16:06, Benedikt Ritter wrote: > commons-logging.jar > commons-logging-adapters.jar > commons-logging-api.jar > > All jars have org.apache.commons.logging as root package, so if I understand > correctly we can’t do the Automatic-Module-Name trick,

Re: [COLLECTIONS] module-info.java and Java 9 (Was: [COLLECTIONS] Time for 4.2)

On 20 September 2017 at 17:12, Benedikt Ritter <brit...@apache.org> wrote: >> Von: Stephen Colebourne <scolebou...@joda.org> >> I've not got maven to work with actual module-info.java files yet on >> the Joda projects, but they are a more complex setup. Maybe >&

Re: [COLLECTIONS] Time for 4.2

On 20 September 2017 at 17:21, Matt Benson <mben...@apache.org> wrote: > On Sep 20, 2017 11:08 AM, "Stephen Colebourne" <scolebou...@joda.org> wrote: > > I think its worth the extra step of checking the conditions are right > for adding the Automatic-Module-N

Re: [COLLECTIONS] Time for 4.2

utomatic-Module-Name MANIFEST header in the >> parent POM and releasing that POM first? > > Stephen Colebourne said that we have to check on a per component basis > whether the component is ready to be released as Java 9 module. For this > reason we wanted to add this to every com

Re: Ready for JDK 9 ?

I didn't get the chance to reply when this thread happened, but really a project should only be viewed as JDK 9 ready when it has had a release with the Automatic-Module-Name entry in the manifest file. AFAIK, only common-lang has this (Although commons-csv, email and jcs were released recently I

Re: [LANG] Add Automatic-Module-Name MANIFEST entry

This looks fine in terms of what it does. Obviously not ideal to have the copying, but that is the right choice to make right now. Stephen On 7 June 2017 at 09:25, Benedikt Ritter wrote: > Hi, > > here [1] is my proposal on how to add the Automatic-Module-Name entry to >

Re: [PARENT][PROPOSAL] Add Automatic-Module-Name MANIFEST entry

On 5 June 2017 at 09:35, Benedikt Ritter wrote: > Is there some documentation on how to check validity? I'm sure there is info in various places, but I've not seen a checklist. Off the top of my head: - all packages under a single super-package that is the module name -

Re: [LANG] Thoughts about Lang 4.0

On 23 May 2017 at 10:13, Jochen Wiedmann wrote: > I am -0 to -1 regarding the introduction of new components. I'd rather > see us redefine the purpose of commons-lang. The experience of > commons-math has demonstrated, IMO, that such new components will most > likely

Re: [all] Java 9 module names

On 24 April 2017 at 11:08, Jörg Schaible <joerg.schai...@bpm-inspire.com> wrote: > Stephen Colebourne wrote: > >> Sounds like you could use --add-modules to add the module separately >> from the command line, or add the module to the application's >> module-

Re: [all] Java 9 module names

not required to compile but is required to run. It appears I have to > convert my runtime scopes to compile in order to get the module to compile > and build properly. > > That sucks. > > Sent from my iPhone > >> On Apr 23, 2017, at 7:43 AM, Stephen Colebourne <sco

Re: [all] Java 9 module names

How does the module system support Maven’s runtime scope? > > Ralph > >> On Apr 21, 2017, at 10:48 PM, Stephen Colebourne <scolebou...@joda.org> >> wrote: >> >> See http://blog.joda.org/2017/04/java-9-modules-jpms-basics.html and >> https:/

Re: [all] Java 9 module names

On 22 April 2017 at 09:00, Emmanuel Bourg <ebo...@apache.org> wrote: > Le 22/04/2017 à 01:02, Stephen Colebourne a écrit : >> I've started a page here: >> https://github.com/jodastephen/jpms-module-names/blob/master/README.md >> Feel free to raise a PR with more proje

Re: [all] Java 9 module names

On 22 April 2017 at 05:18, Matt Sicker wrote: > Despite all the shit the Java champions talk about OSGi, Jigsaw is still a > simplified version of OSGi basically, so anything already supported via > OSGi will generally port extremely easily to Java 9 modules. JPMS (Jigsaw) is

Re: [all] Java 9 module names

will be sure >> to submit a PR when I get something going with Log4j 2. >> >> Ralph >> >>> On Apr 21, 2017, at 3:01 PM, Stephen Colebourne <scolebou...@joda.org> >>> wrote: >>> >>> Some rules: >>> - Each module co

Re: [all] Java 9 module names

commons.lang3.reflect; > exports org.apache.commons.lang3.text; > exports org.apache.commons.lang3.text.translate; > exports org.apache.commons.lang3.time; > exports org.apache.commons.lang3.tuple; > } > > Stephen > > On 21 April 2017 at 13:31, Emmanuel Bourg <ebo...@apach

Re: [all] Java 9 module names

this? > > Ralph > >> On Apr 21, 2017, at 6:16 AM, Stephen Colebourne <scolebou...@joda.org> wrote: >> >> On 21 April 2017 at 13:59, sebb <seb...@gmail.com> wrote: >>> What happens when there is a API break which necessitates a package name >>> c

Re: [all] Java 9 module names

On 21 April 2017 at 13:59, sebb wrote: > What happens when there is a API break which necessitates a package name > change? > I assume that the module name will also need to change to the new > super-package. > e.g. > > Commons-Lang4 > -> super-package org.apache.commons.lang4

Re: [all] Java 9 module names

org.apache.commons.lang3.tuple; } Stephen On 21 April 2017 at 13:31, Emmanuel Bourg <ebo...@apache.org> wrote: > Le 21/04/2017 à 14:00, Stephen Colebourne a écrit : > >> Comments? Questions? > > Hi Stephen, > > Thank you for stopping by and enlightening us about JPMS. The

[all] Java 9 module names

Hi All, Java 9 is coming soon (unless it is delayed again, but that seems unlikely). The major feature is JPMS, the Java Platform Module System. While JPMS is far from ideal, projects like Apache Commons and mine Joda-* are going to be key to getting some adoption. This is particularly true as

Re: [OT] Anyone going to JavaOne?

I'll be there talking three times. Usually best to find me after one of the talks... http://blog.joda.org/2013/09/speaking-at-javaone2013.html Stephen On 19 September 2013 20:50, James Carman ja...@carmanconsulting.com wrote: Is anyone planning on going? It would be great to meet some of you

Re: [ALL] How to handle static imports [was: Re: svn commit: r1441784 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/PropertyDescriptorsRegistry.java]

FYI, the Project Lambda Streams code and JSR-310 in JDK 1.8 are both written with static imports in mind. Moreover, with support for static methods in interfaces being added, this is likely to increase as a pattern. Those facts may or may not affect decisions in commons. Stephen On 4 February

Re: [weaver]/[bcel] WAS [privilizer] promotion plan

On 4 December 2012 23:05, Gary Gregory garydgreg...@gmail.com wrote: I like the name weaver. Does it make sense to allow different libs to be plugged in? BCEL, ASM... Or do do we have to pick one? Based on what I see in various projects, ASM won, BCEL lost. Main problem tends to be different

Re: [csv] CSVFormat API names

On 16 October 2012 17:44, Matt Benson gudnabr...@gmail.com wrote: On Tue, Oct 16, 2012 at 11:42 AM, James Carman ja...@carmanconsulting.com wrote: On Tue, Oct 16, 2012 at 12:38 PM, Matt Benson gudnabr...@gmail.com wrote: Are these specific examples not the words you would actually use were

Re: [collections] Cleanup of trunk

://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Jul 4, 2012 at 9:59 AM, Jörg Schaible joerg.schai...@scalaris.com wrote: Stephen Colebourne wrote: On Java 5/6, I'm in favour of Java 6 at this point. To justify it for Sebb, someone needs to check to see if any collections

Re: [collections] Cleanup of trunk

On Java 5/6, I'm in favour of Java 6 at this point. To justify it for Sebb, someone needs to check to see if any collections in [collections] could implement the new interfaces added in Java 6 - NavigableSet, NavigableMap and so on. Stephen On 24 June 2012 12:25, sebb seb...@gmail.com wrote:

Re: Conversion utility class

On 4 February 2012 05:38, ma...@nimp.co.uk ma...@nimp.co.uk wrote: Apache Commons Lang seems to be the right place for that kind of utility class, however, my utility class is coded in Scala, is that ok ? Not in my opinion No. I have no problem with a Scala-only commons component, but I think

Re: [lang] 3.2?

On 31 December 2011 08:45, Henri Yandell flame...@gmail.com wrote: Three changes of interest. Two are the removal of final on public methods. The other is the addition of Serializable to StrBuilder. As described above, those are source and binary compatible. Stephen Which is the worry? And

Re: [jira] [Commented] (LANG-577) Add ObjectReference interface and two implementations

Oracle advise using AtomicReference for any threaded cases, and we have MutableObject for other cases. I'm very dubious about adding a second version of the same class. Stephen Limited mobile access On 11/09/2011, Henri Yandell (JIRA) j...@apache.org wrote: [

Re: [lang] Running lang under a security manager and LANG-744

On 2 September 2011 01:20, Gary Gregory garydgreg...@gmail.com wrote: Specifically for StringUtils, should we have a SunStringUtils? This would let you know that you are depending on com.sun code. I really don't like that idea! Generally, it is non-Sun JVMs including Android that are the

Re: [codec] Encoder / Decoder interface

On 17 August 2011 13:44, Matthew Pocock turingatemyhams...@gmail.com wrote: It seems to me that the Encoder/Decoder interfaces are screaming out to be generified, and the current sub-interfaces should be removed unless there's a compelling reason for them e.g. if they add extra methods. It is

Re: [codec] getting the bmpm code out there

I've just noticed this thread. I'd like to ask those involved to consider if they can find a route where the package name and group do *not* change. - Changing to JDK 5 does not require a a package name change (generics are backward compatible if the erased signatures don't change). - Removing

Re: [codec] getting the bmpm code out there

On 12 August 2011 11:19, sebb seb...@gmail.com wrote: - Removing deprecated methods does not require a package name change How so? If there are any external references to them in an application that cannot be removed, then both old and new jars will need to be deployed. Which cannot be

Re: [codec] getting the bmpm code out there

On 12 August 2011 14:54, sebb seb...@gmail.com wrote: We have lang3 and digester3 under our belts now with new packages. Are we going to change policy again? I hope not. We sure spent a lot of time on this and thought we made a sane decision as a community. Joda-time is its own world can do

Re: [collections] 4.0 release path

of generics-RnD. Hen On Wed, Aug 3, 2011 at 8:23 AM, Stephen Colebourne scolebou...@joda.org wrote: I think that a key mistake was trying to do both generics and refactoring. I'd suggest that quite a few users would simply like a generified [collections] 3.5 that is fully backwards

Re: [collections] 4.0 release path

one method and then release [to take it to extremes]. Hen On Fri, Aug 5, 2011 at 12:33 AM, Stephen Colebourne scolebou...@joda.org wrote: I agree with this. And I think it serves users better, many of whom have migrated to Google Guava. 1) New bug fix only release, JDK 1.4 compatible 2) New

Re: [logging] logging vs slf4j

My thought is that there might be some java.util.logging helpers that could be written, and perhaps they might go in [lang] if there are 5 or fewer classes. I assume that slf4j and log4j have their own j.u.logging connections, so that end is dealt with. The time of [logging] has probably passed.

Re: [collections] 4.0 release path

I think that a key mistake was trying to do both generics and refactoring. I'd suggest that quite a few users would simply like a generified [collections] 3.5 that is fully backwards compatible (as the JDK was) and with no refactoring. Now, some of the API cannot be generified correctly, so for

Re: [LANG] Commons Lang 3.0

You will need both versions of commons-lang, the new and the old. Stephen On 27 July 2011 11:17, Rohan Kadam roha...@cybage.com wrote: Hi All, We have upgraded our common lang jar to 3.0 version. We have replaced package name lang to lang3. But since it has already been mentioned on apache

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

it is OK to also depend on [io] for testing as well. CP'ing code is lame in this case IMO. Gary Hen On Mon, Jul 18, 2011 at 3:50 PM, Stephen Colebourne scolebou...@joda.org wrote: StringEscapeUtils test includes IOUtils, which it shouldn't. (If its been added

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

On 19 July 2011 16:32, Gary Gregory garydgreg...@gmail.com wrote: When you say Personally, I'm OK with using JUnit and mocking utilities as they are both specifically intended for testing. are you thinking that there are alternative solutions?. IMO, JUnit is a requirement, not something we

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

I'm willing to vote +1 Although I haven't checked every recent change, but AFAIK recent changes have been minor and my previous issues are resolved. I would note that the svn as of right now does not compile, due to an IOUtils reference that shouldn't be there. Stephen On 16 July 2011 01:18,

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

StringEscapeUtils test includes IOUtils, which it shouldn't. (If its been added as a dependency, then it needs to be removed, even for testing) Stephen On 18 July 2011 23:41, Gary Gregory garydgreg...@gmail.com wrote: On Jul 18, 2011, at 18:36, Stephen Colebourne scolebou...@joda.org wrote

Re: [graph collections] Fibonacci Heap implementation

I think from the quiet reply its apparent that [collections] is pretty quiet these days. I think [collections] development must focus first on a release of a Java 5 version of what it has, rather than new code. Stephen On 14 July 2011 01:19, Simone Tripodi simonetrip...@apache.org wrote: Hi all

Re: [lang] RC4 heads up

On 12 July 2011 18:56, Jörg Schaible joerg.schai...@gmx.de wrote: 1/ FastDateFormat The date format yyy yy y is formatted with JDK 7 as 2003 2003 03 2003 instead of 2003 03 03 03. So, should FastDateFormat follow the JDK in any case and adjust its result according the runtime?

[lang] Contexted exception [Re: [lang] Time for RC3?]

On 7 July 2011 00:57, Jörg Schaible joerg.schai...@gmx.de wrote: Proposed changes done. Please review, especially also Javadoc as I'm a non- native speaker. Done. I think you could remove the add/set methods taking a Pair. The other add/set methods taking two arguments is sufficient, and I

Re: [lang] Contexted exception [Re: [lang] Time for RC3?]

On 7 July 2011 11:48, Jörg Schaible joerg.schai...@scalaris.com wrote: One last opinion about the output? Originally we had e.g.:  [Handler = PersonConverter]  [Current Element = Person]  [Role = COO]  [Handler[1] = CompanyConverter]  [Current Element[1] = Company] The current output does

Re: [lang] Time for RC3?

On 4 July 2011 23:13, Jörg Schaible joerg.schai...@gmx.de wrote: Sorry, why is setValue more vague - isn't it the other way round? As a method name, replace is explicit, set slightly less so. Either work here, so if you want to change it go ahead. More generally, I now think the index suffix

Re: [lang] Time for RC3?

On 6 July 2011 09:52, Jörg Schaible joerg.schai...@scalaris.com wrote: I can traverse now the set of keys to get this list when it is internally implemented with a LinkedHashMap. Remember, one important element of a contexted exception is a more informational and structured message. In the

Re: [lang] Time for RC3?

On 6 July 2011 21:45, Jörg Schaible joerg.schai...@gmx.de wrote: Since the ExceptionContext is especially designed for an exception mix-in, I wonder if we better use more qualifying names for this use case: interface ExceptionContext {  addContextValue(...);  setContextValue(...);  

Re: [lang] Time for RC3?

On 3 July 2011 22:04, Gary Gregory garydgreg...@gmail.com wrote: * Email thread - what else should implement Formattable? I would look at this differently to get 3.0 out the door: Let's make sure we do not make anything Formattable that we might have to back out later. Currently, nothing

Re: [lang] Time for RC3?

On 3 July 2011 19:07, Gary Gregory garydgreg...@gmail.com wrote: http://markmail.org/message/ml7efpvqezysvs2p?q=Validate+list:org%2Eapache%2Ecommons%2Edev/ Since this has gone quiet, I was going to follow through and rename the validate* method (which are all @since 3.0) to check*. Someone

Re: [lang] Time for RC3?

On 2 July 2011 15:28, Jörg Schaible joerg.schai...@gmx.de wrote: Can somebody else give the ContextedException stuff a review? I used in the meanwhile a copy of it in a project, but a method name is bugging me. The structure looks reasonable to me. While you could rename replaceValue() to

Re: [DISCUSS] codebase looking for a place to be contributed to commons

I've used scannotation before, which is reasonably well known I believe, but could probably be improved on. I think with multiple versions at Apache, it is a perfect concept for commons. I would check out [discovery] first to see if that has a similar goal. I'd set it up separately to [lang]

Re: svn commit: r1127546 - in /commons/proper/lang/trunk/src: main/java/org/apache/commons/lang3/tuple/Pair.java test/java/org/apache/commons/lang3/text/FormattableUtilsTest.java

The discussion threads ended with both th notion that Formattable was adding no value and final was best added for safety. I checked before making the change. Feel free to propse alternatives... Stephen On 25 May 2011 15:48, Matt Benson gudnabr...@gmail.com wrote: Way to make unilateral

Re: [math] [sandbox] merging Apache Commons BSP into Apache Commons Math

On 18 May 2011 09:11, Luc Maisonobe luc.maison...@free.fr wrote: Should I replace with one-d, two-d and three-d ? Of course this should read: one_d, two_d and three_d ... In the variety of Java source I've seen, multiple words are scrunched together, giving oned, twod, threed. Stephen

[lang] Immutable classes (Pair/Range etc)

This issue about what immutable means wrt final on the class has bounced around a few threads. In my view, immutable has a specific meaning, whereby the object is unequivically safe to use and share between threads. To do so, there are certain rules. One that is disputed is whether the class must

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

On 18 May 2011 17:46, Matt Benson gudnabr...@gmail.com wrote: On Wed, May 18, 2011 at 11:32 AM, Gary Gregory garydgreg...@gmail.com wrote: Why doesn't a Range does extend Pair? It's pretty clear (to me at least) that a range is a pair of values. Because the Pair is in our tuple package, it

Re: [lang] Immutable classes (Pair/Range etc)

On 18 May 2011 17:58, Matt Benson gudnabr...@gmail.com wrote: On Wed, May 18, 2011 at 11:47 AM, Stephen Colebourne scolebou...@joda.org wrote: This issue about what immutable means wrt final on the class has bounced around a few threads. In my view, immutable has a specific meaning, whereby

Re: [lang] Immutable classes (Pair/Range etc)

On 18 May 2011 18:09, Stephen Colebourne scolebou...@joda.org wrote: See the EvilFoo example above. Any ability to subclass, even with safe methods, means its not completely thread-safe. More info: StringBuilder evilBuf = new StringBuilder(); EvilFoo evilFoo = new EvilFoo(evilBuf); doStuff

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

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

Re: FormattableUtils

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

  1   2   3   >