en
On Mon, 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:
> >
> &g
en-checkstyle-plugin: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 seb
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
ma
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 permiss
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 th
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 d
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 int
um, you get flexible 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 p
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 q
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.
T
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 07:35:12
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, Krz
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
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
ht
_____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
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 classes
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 with
> NullPointerExc
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 of
> it.
Then those tools ne
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
modu
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 Feb 2018 08:30:00 -0700, Gary Gre
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
> better: Fraction.from(num,
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, 8 Jan 2018 22:23:08 -0800, Chas
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?
>
> Updating from BU 1.x to 2.x sh
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 Commons DBCP 2.2.
>
> I plan
; 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 Verburg[2].
>
> 1. Initial
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 Commons-Mat
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
> souls trying out Java 10 EA.
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
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 RC1 is available for
g the default goal of the pom ("mvn clean verify
> apache-rat:check clirr:check checkstyle:check findbugs:check
> javadoc:javadoc")
>
> It would be nice if you could update the pull request, so that we do not
> lose these additional automated checks.
>
> Thank
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 understand
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 change must use new module
t;>>> 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
>>>> up all over itself because it was incorrectly trying to do something with
>>>> t
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 major version change. Its just one more .clas
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
>> automatic module name
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 unsubscribe, e-mail: dev-un
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: dev-unsubscr...@commons
ntral. (In fact, why not
just delete their creation in pom.xml ?)
Stephen
On 26 September 2017 at 22:05, Benedikt Ritter wrote:
>
>> Am 26.09.2017 um 22:54 schrieb Stephen Colebourne :
>>
>> On 26 September 2017 at 18:48, Jörg Schaible wrote:
>>> AFAICS we have only c
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 unsubscribe, e-mail: dev-unsubscr..
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, because this would
> requ
On 20 September 2017 at 17:12, Benedikt Ritter wrote:
>> Von: Stephen Colebourne
>> 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
>> [collections] could be the first to get a real
On 20 September 2017 at 17:21, Matt Benson wrote:
> On Sep 20, 2017 11:08 AM, "Stephen Colebourne" wrote:
>
> I think its worth the extra step of checking the conditions are right
> for adding the Automatic-Module-Name manifest entry.
>
>
> Wouldn't that j
nt 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 component individually. At least that
> is what I recall.
&g
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 d
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
> MANIFEST. This just dup
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
- jdeps shows no use of int
On 25 May 2017 at 17:23, Oliver Heger wrote:
> I also think that a new major release just to fix this problem would be
> overkill and cause clients even more trouble.
>
> Would the following approach work as a compromise:
>
> - [lang] declares an optional dependency to the desktop module.
> - All
On 24 May 2017 at 15:55, Rob Tompkins wrote:
> We should simply add that entry, "commons.automatic-module-name," to every
> component pom’s properties section now, and then when the next parent
> migration happens, the changes will express naturally. It might be worth
> adding a comment on the
On 23 May 2017 at 17:17, sebb wrote:
>> Yes, the
>> code compiles and both can be on the classpath, but it is a pain to
>> use, just a different kind of hell.
>
> I don't see what the problem is here.
Library A that depends on lang3 returns a Pair.
Library B that depends on lang4 takes a Pair.
Ap
On 23 May 2017 at 16:07, sebb wrote:
> Huh?
>
> The whole point of changing the package name and Maven coords is to
> allow mutually incompatible jars to coexist peacefully on a single
> classpath.
All you are doing in replacing one kind of jar hell with another.
Removing these methods means tha
On 23 May 2017 at 11:54, sebb wrote:
>> Fixing it properly requires a major release, which implies that Lang
>> 4.0 is still Java 1.7 and should use the `org.apache.commons.lang3`
>> package name.
>
> I think that depends on whether the API is backwards-compatible or not.
>
> If it *is* backwards-
On 22 May 2017 at 00:56, Benedikt Ritter wrote:
> I think the time has come to start thinking about Lang 4.0.
As I outlined in another thread, Lang 3.5 uses PropertyChangeListener,
which in module terms pulls in the whole of Swing and AWT. For a
library like [lang] that is a bad thing and should
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 increase the noise without an
On 22 May 2017 at 23:29, Gary Gregory wrote:
> Don't you mean 4.0 since changing:
>
> - AbstractCircuitBreaker.addChangeListener(PropertyChangeListener)
> - AbstractCircuitBreaker.removeChangeListener(PropertyChangeListener)
>
> would break BC?
No. I meant 3.7. [lang] has a problem with versionin
I took a stab at adding module-info.java to [lang]:
https://github.com/jodastephen/commons-lang/commit/5d5dd6809eeef90ea2b6245c0d0a488fb917e30a
Since the maven-bundle-plugin isn't working, I had to use antrun to
copy the module-info.class file out and back in again. A gross hack.
There are two ke
On 22 May 2017 at 12:51, Rob Tompkins wrote:
> You could, in the parent, declare in the properties section beside the
> declaration of “commons.osgi.symbolicName”, another property pointing to that
> as
>
> ${commons.osgi.symbolicName}
>
> and then allow people to override that in their local po
On 22 May 2017 at 00:32, Benedikt Ritter wrote:
> This is not as straight forward as I thought. Simply adding
>
> ${commons.automatic-module-name}
>
> Does not work, since this will add an empty entry to the resulting manifest
> file, if a component does not specify the commons.automatic-module-n
Is reusing ${commons.osgi.symbolicName} a good idea?
It seems to me that each project should have to opt-in to this
attribute, so I'd add a new ${commons.automatic.moduile.name}
variable.
One reason is that the attribute should only be added if the project
is suitable for use as a module (eg. no p
On 17 May 2017 at 21:44, Benedikt Ritter wrote:
>> Automatic-Module-Name: org.apache.commons.lang3
>>
>> This allows other projects to safely depend on [lang3]. Ultimately,
>> we'll have to add a module-info, but this is a much simpler first
>> step.
>
> It’s nice to see you being more active at C
Not sure when the next planned release is, but it might be worth
adding the proposed entry in MANIFEST.MF for modules. It isn't
guaranteed to be in the final JDK 9, but my best guess is that it
won't change now. It would involve making a pom.xml change to add this
to the manifest:
Automatic-Module
On 24 April 2017 at 11:08, Jörg Schaible 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-info rather than the libraries.
>>
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 wrote:
>>
>> I
ule system support Maven’s runtime scope?
>
> Ralph
>
>> On Apr 21, 2017, at 10:48 PM, Stephen Colebourne
>> wrote:
>>
>> See http://blog.joda.org/2017/04/java-9-modules-jpms-basics.html and
>> https://www.slideshare.net/scolebourne/java-se-9-modules-jpms-a
On 22 April 2017 at 09:00, Emmanuel Bourg 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 projects at commons or el
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 not a simplified OSG
n’t yet been modularized? Normally I would expect to have requires
> directives.
>
> Ralph
>
>> On Apr 21, 2017, at 6:04 PM, Ralph Goers wrote:
>>
>> Thanks for taking a look Stephen. I appreciate the guidance. I will be sure
>> to submit a PR when I get somethin
ommons.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 wrote:
>> L
.logging.log4j.core.
> These obviously overlap. Most of our other jars have packages that are in
> org.apache.logging.log4j.xxx where xxx matches the jar name. We aren’t going
> to change the API to support modules.
>
> Is there some reasonable way around this?
>
> Ralph
&
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
> -> module org.ap
lang3.time;
exports org.apache.commons.lang3.tuple;
}
Stephen
On 21 April 2017 at 13:31, Emmanuel Bourg 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 n
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 Comm
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 wrote:
> Is anyone planning on going? It would be great to meet some of you
> guys face-to-face for once
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 20
On 4 December 2012 23:05, Gary Gregory 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 versions of ASM bei
On 16 October 2012 17:44, Matt Benson wrote:
> On Tue, Oct 16, 2012 at 11:42 AM, James Carman
> wrote:
>> On Tue, Oct 16, 2012 at 12:38 PM, Matt Benson wrote:
>>>
>>> Are these specific examples not the words you would actually use were
>>> you having a discussion on the subject in English? :P
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>> On Wed, Jul 4, 2012 at 9:59 AM, Jörg Schaible
>> wrote:
>>> Stephen Colebourne wrote:
>>>
>>>> On Java 5/6, I'
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 wrote:
> On 24 June 2012
On 4 February 2012 05:38, 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
mixing two lang
On 31 December 2011 08:45, Henri Yandell 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 is it a big enou
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) wrote:
>
> [
> https://issues.apache.org/jira/browse/LANG-
On 2 September 2011 01:20, Gary Gregory 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 problem.
Lets just do the
On 17 August 2011 13:44, Matthew Pocock 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 no
> hardship in your code
On 12 August 2011 14:54, sebb 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 what it wan
On 12 August 2011 11:19, sebb 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 done safely
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 de
cize one method and then release [to take it to extremes].
>
> Hen
>
> On Fri, Aug 5, 2011 at 12:33 AM, Stephen Colebourne
> wrote:
>> I agree with this. And I think it serves users better, many of whom
>> have migrated to Google Guava.
>>
>> 1) New bug fix on
to start on 4.0, pulling
> over the remainder of generics-RnD.
>
> Hen
>
>
> On Wed, Aug 3, 2011 at 8:23 AM, Stephen Colebourne
> wrote:
>> I think that a key mistake was trying to do both generics and
>> refactoring. I'd suggest that quite a few users woul
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 a
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.
You will need both versions of commons-lang, the new and the old.
Stephen
On 27 July 2011 11:17, Rohan Kadam wrote:
> Hi All,
>
> We have upgraded our common lang jar to 3.0 version. We have replaced package
> name "lang" to "lang3". But since it has already been mentioned on apache
> website t
On 19 July 2011 16:32, Gary Gregory 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 should even consider
. Dealing with
>> >> something like that is something the build system needs to know how to
>> >> do.
>> >>
>> >
>> > We depend on JUnit and EasyMock for testing, so I really think it is OK
>> to
>> > also depend on [io] for testing
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 wrote:
> Hi all guys,
> in order to impr
StringEscapeUtils test includes IOUtils, which it shouldn't. (If its
been added as a dependency, then it needs to be removed, even for
testing)
Stephen
On 18 July 2011 23:41, Gary Gregory wrote:
> On Jul 18, 2011, at 18:36, Stephen Colebourne wrote:
>
>> I'm willing to
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, He
On 12 July 2011 18:56, Jörg Schaible wrote:
> 1/ FastDateFormat
> The date format " yyy yy y" is formatted with JDK 7 as "2003 2003 03
> 2003" instead of "2003 03 03 03". So, should FastDateFormat follow the JDK
> in any case and adjust its result according the runtime? Interestingly
> Javadoc
On 7 July 2011 11:48, Jörg Schaible 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 no longer have the
On 7 July 2011 00:57, Jörg Schaible 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 can't
see when the Pair
On 6 July 2011 21:45, Jörg Schaible 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(...);
> getContextValues(...);
On 6 July 2011 09:52, Jörg Schaible 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
> list above I can see quite
1 - 100 of 253 matches
Mail list logo
