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

[Chas Honton]

What’s the minimum target jre?  If 8 or later, use java.util.BiConsumer.  
Otherwise, create a custom @FunctionalInterface. 

Chas

> On Jun 10, 2018, at 2:52 PM, Bruno P. Kinoshita 
>  wrote:
> 
> Great catch indeed Gilles.
> 
> 
> So perhaps just leave the deprecated, with no replacement? And then add a 
> note in the next release that those classes will be removed in the future?
> 
> B
> 
> 
> From: Stephen Colebourne 
> To: Commons Developers List  
> Sent: Monday, 11 June 2018 9:26 AM
> Subject: Re: [LANG] Java 9 problems because of dependencies to java.desktop 
> (Was: Re: [LANG] Thoughts about Lang 4.0)
> 
> 
> 
> Good spot. I think that means [lang] would have to have its own copy
> of the JDK interfaces. or just deprecate the functionality without
> replacement.
> Stephen
> 
>> On 10 June 2018 at 22:11, Gilles  wrote:
>> Hello.
>> 
>>> On Sun, 10 Jun 2018 21:34:49 +0200, Oliver Heger wrote:
>>> 
>>> Hi Bruno,
>>> 
 Am 10.06.2018 um 00:52 schrieb Bruno P. Kinoshita:
 
 Hi all,
 
 There is a patch [1] for LANG-1339 [2] that I would like to merge. The
 discussion around this issue can be found in the rest of this e-mail 
 thread.
 
 The patch basically deprecates the existing classes that depend on
 java.desktop, and provide alternative implementations. The previous classes
 used java.desktop classes for the PropertyChangeListener. And the
 alternative ones instead use Java 7's java.util.Observer.
>> 
>> 
>> Is it a good idea to use deprecated classes[1] in new code?
>> 
>> Regards,
>> Gilles
>> 
>> [1] https://docs.oracle.com/javase/9/docs/api/java/util/Observable.html
>> 
>> 
 
 
 This will make it easier to provide [lang] as java 9, without requiring
 users to include a dependency to java.desktop.
 Planning to merge it during the next week if there are no objections
 here.
 
 Thanks,
 Bruno
>>> 
>>> 
>>> agreed. This seems to be the best what we can do.
>>> 
>>> Oliver
>>> 
 
 
 [1] https://github.com/apache/commons-lang/pull/275
 
 [2] https://issues.apache.org/jira/browse/LANG-1339
 
 
 
 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)
 
 
 
 
> Am 25.05.2017 um 18:23 schrieb Oliver Heger
> :
> 
> 
> 
>> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
>> 
>> 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.
>> Application cannot pass Pair from A to the B without conversion.
>> 
>> My point is that it is possible to over-worry about jar hell.
>> Joda-Time removed some methods when it went from v1.x to v2.x, but
>> didn't change package name or maven co-ordinates. It was far more
>> important that end-users didn't have two different LocalDate classes
>> (a problem that couldn't be avoided when moving to Java 8). I've never
>> seen any feedback about the incompatibility causing jar hell.
>> 
>> The same is true here. It is vital to think properly about which is
>> the worse choice, not just assume that jar hell must always be
>> avoided.
>> 
>> I remain completely unconvinced that removing these two problematic
>> methods justifies the lang4 package name, forcing end-users to have
>> three copies of the library on the classpath. It should need much,
>> much more to justify lang4 package name. In fact I've yet to hear
>> anything else much in this thread that justifies a major release.
> 
> 
> 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 affected classes (AbstractCircuitBreaker and its two sub classes)
> are marked as deprecated.
> - Copies are created from the original classes with slightly changed
> names or in a new package (tbd). These copies use a new change listener
> mechanism.
> 
> IIUC, the resulting [lang] module can now be used without the dependency
> to desktop when the new classes are used. The dependency will only be
> needed for the deprecated versions.
 
 
 Let’s do it like this. Sounds like the right way to me.
 
 Benedikt
 
> 
> Oliver
> 
>> 
>> Stephen
>> 
>> 
>> 

Re: commons-csv git commit: CSV-216: Avoid Arrays.copyOf()

[Chas Honton]

Read Bloch.  Don’t optimize until you have proven that this bit of code is 
causing a significant performance hit. 
arrayCopy can and is inlined by jit. 

Chas

> On Feb 16, 2018, at 5:53 AM, Stian Soiland-Reyes  wrote:
> 
> String is still a type of Object (requiring GC handling of reference
> counters), as you can do Object[] o = stringArray.clone(); without
> casting.  (other way not so)
> 
> https://www.javaspecialists.eu/archive/Issue124.html says there is
> hardly any difference, so I don't think we need to fight this one out
> and can just go with the cleanest code :)
> 
>> On 16 February 2018 at 11:22, sebb  wrote:
>>> On 16 February 2018 at 10:01, Stian Soiland-Reyes  wrote:
>>> I agree in general for .clone() on objects - and I'm trying to move
>>> away from using .clone() in that Commons RDF fluent mutable/immutable
>>> builder (See COMMONSRDF-49).
>>> 
>>> But this is an Object[] - a native type.
>> 
>> Huh?
>> 
>> The code says String[], which is native as it's final.
>> 
>> Object[] may not be native
>> 
>>> I must admit I am not sure what is really the preferred way - I
>>> thought .clone() is best as the VM can copy an array natively however
>>> it wants, while with Arrays.copyOf it might have to check if length is
>>> the same before doing anything clever.
>> 
>> In the specific case of String[] it might be OK to use clone, but in
>> general it's better to use the proper JVM methods and not try to
>> second-guess how efficient they are.
>> 
 On 13 February 2018 at 18:58, Gilles  wrote:
> On Tue, 13 Feb 2018 18:40:13 +, sebb wrote:
> 
>> On 13 February 2018 at 09:31, Gilles  
>> wrote:
>> 
>>> On Tue, 13 Feb 2018 00:16:13 + (UTC), st...@apache.org wrote:
>>> 
>>> 
>>> Repository: commons-csv
>>> Updated Branches:
>>>  refs/heads/CSV-216 637ad2d7a -> f66a83901
>>> 
>>> 
>>> CSV-216: Avoid Arrays.copyOf()
>> 
>> 
>> 
>> Why?
> 
> 
> Agreed
> 
>>> as .clone() will do
>> 
>> 
>> 
>> We should rather avoid using "clone()".
> 
> 
> Again: why?
 
 
 There are many discussions about this topic on the web.[1]
 My point is that using "clone()" is not good advice.
 
 Gilles
 
 [1] E.g. http://vojtechruzicka.com/java-cloning-problems/
 
 
> It's not clear why Arrays.copyOf(0 is considered bad, nor why clone()
> is considered bad.
> 
> 
>> Gilles
>> 
>> 
>>> -- at least until someone tries to do
>>> .withValue(x) in an out-of-range column
>>> 
>>> 
>>> Project: http://git-wip-us.apache.org/repos/asf/commons-csv/repo
>>> Commit:
>>> http://git-wip-us.apache.org/repos/asf/commons-csv/commit/f66a8390
>>> Tree: http://git-wip-us.apache.org/repos/asf/commons-csv/tree/f66a8390
>>> Diff: http://git-wip-us.apache.org/repos/asf/commons-csv/diff/f66a8390
>>> 
>>> Branch: refs/heads/CSV-216
>>> Commit: f66a83901bd026369a2e8d522bd567eb2ef3f8c0
>>> Parents: 637ad2d
>>> Author: Stian Soiland-Reyes 
>>> Authored: Fri Feb 9 16:49:51 2018 +
>>> Committer: Stian Soiland-Reyes 
>>> Committed: Tue Feb 13 00:14:52 2018 +
>>> 
>>> 
>>> 
>>> --
>>> src/main/java/org/apache/commons/csv/CSVRecord.java | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>> 
>>> 
>>> --
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> http://git-wip-us.apache.org/repos/asf/commons-csv/blob/f66a8390/src/main/java/org/apache/commons/csv/CSVRecord.java
>>> 
>>> 
>>> --
>>> diff --git a/src/main/java/org/apache/commons/csv/CSVRecord.java
>>> b/src/main/java/org/apache/commons/csv/CSVRecord.java
>>> index 979119f..2be5c49 100644
>>> --- a/src/main/java/org/apache/commons/csv/CSVRecord.java
>>> +++ b/src/main/java/org/apache/commons/csv/CSVRecord.java
>>> @@ -199,7 +199,7 @@ public class CSVRecord implements Serializable,
>>> Iterable {
>>> public final CSVRecord immutable() {
>>>if (isMutable()) {
>>>// Subclass is probably CSVMutableRecord, freeze values
>>> -   String[] frozenValue = Arrays.copyOf(values,
>>> values.length);
>>> +   String[] frozenValue = values.clone();
>>>return new CSVRecord(frozenValue, mapping, comment,
>>> recordNumber, characterPosition);
>>>} else {
>>>return this;
>>> @@ -260,7 +260,7 @@ public class CSVRecord implements Serializable,
>>> Iterable {
>>>if 

Re: [text] Adapt the Log4j 2 Interpolator to [text]

[Chas Honton]

Definitely create interfaces. 

Chas

> On Feb 11, 2018, at 1:57 PM, Gary Gregory  wrote:
> 
> On Sun, Feb 11, 2018 at 2:46 PM, Gary Gregory 
> wrote:
> 
>> 
>> 
>> On Sun, Feb 11, 2018 at 12:05 PM, Pascal Schumacher <
>> pascalschumac...@gmx.net> wrote:
>> 
 Am 11.02.2018 um 19:24 schrieb Gary Gregory:
 
 I'd like a code review and then a release of 1.3. Right now we only
 depend
 on java.base and Commons Lang, so let's keep it that way for 1.3 I think.
 
>>> My comments:
>>> 
>> 
>> Thank you for the code review!
>> 
>> 
>>> - Given "TEXT-80: StrLookup API confusing generic type parameter" I think
>>> we should deprecate the old StrLookup class and mark it for removal in
>>> commons-text 2.0.
>>> 
>> +1 and will do.
>> 
>> 
>>> - DateStringLookup: should we use FastDateFormat?
>>> 
>> 
>> I overlooked that one, I'll look into it.
>> 
>> 
>>> - AbstractStringLookup: empty class, I would therefore remove it.
>>> 
>> 
>> I like to have it around for now, it is package private anyway. We can
>> remove it before 1.3 if it stays empty. At one point I have an
>> isEmpty(String) method in there before I realized that Commons Text depends
>> on Commons Lang which provides the same service in
>> StringUtils.isEmpty(String).
>> 
>> 
>>> - StringLookupFactory: should this be a static factory, to make it easier
>>> to use?
>> 
>> 
>> I am leaving room for configuring these things later so I feel that doing
>> .INSTANCE is a small price to pay but I hear you.
>> 
> 
> Oh, and consider this alternative:
> 
> - Create StringLookup (already there) and StringSubstitutor
> - Deprecate StrLookup and StrSubstitutor and leave as is from 1.2
> - ALSO deprecate StrMatcher which is a class and introduce a StringMatcher
> _interface_.
> 
> The idea here is to avoid having to do this a second time later. Right now
> StrLookup and StrMatcher are classes, there are no interfaces. The question
> is: Should we just redo the whole thing based on interfaces now. As of now
> in master, we have a 50/50 situation with StrSubstituor supporting both
> StrLookup and StringLookup AND using StrMatcher (a class, not an interface).
> 
> Thoughts?
> 
> Gary
> 
> 
>> Gary
>> 
>> 
>>> 
>>> 
>>> (I almost added Log4j's JNDI lookup but I know that will not work on
 Android so I'd like to leave stuff like that for later, maybe in a
 different module.)
 
>>> +1 for leaving it out
>>> 
>>> -Pascal
>>> 
>>> 
>>> -
>>> 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: Parent POM and automatic module name

[Chas Honton]

Profile triggers in src/profiles?

Chas

> On Jan 8, 2018, at 4:27 PM, sebb  wrote:
> 
>> On 8 January 2018 at 23:14, Jörg Schaible  wrote:
>> Am Mon, 08 Jan 2018 00:48:08 + schrieb sebb:
>> 
>>> On 8 January 2018 at 00:25, Jörg Schaible  wrote:
>> 
>> [snip]
>> 
> The component poms I checked all include a comment like "Temporary
> fix, remove this after this has implemented in parent pom". As these
> comments are not true anymore I will remove those I find.
 
 It is possible to define a profile in parent and trigger it as opt-in
 based on the existence of a file.
 
 Do we have any precedence for triggering profiles based on file
 existence in commons? Typical name patterns used are:
 - profile/ - profiles/
 - .profile
>>> 
>>> Yes, e.g. jacoco
>> 
>> Found it:
>> 
>> - src/site/resources/profile.
>> 
>> However the location for these profile files does not make sense in general. 
>> And definitely not for a profile
>> adding the module name :-/
>> 
>> Alternatives? Common location for such a profile activation?
> 
> src/site/resources was chosen because Jacoco is used for the site build.
> I don't think such files should should be moved.
> 
> But by all means find somewhere else for new profile triggers.
> 
>> Cheers,
>> Jörg
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 

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

Re: [parent] Release commons-parent 43

[Chas Honton]

+1 to Jorge ‘s comments 

Chas

> On Jan 2, 2018, at 3:05 AM, sebb  wrote:
> 
> +1
> 
> Unlike components, there's no harm releasing CP as its usage is under
> our control.
> If it turns out there is a problem with CP 43, then we can just ignore it.
> 
>> On 2 January 2018 at 09:00, Pascal Schumacher  
>> wrote:
>> +1
>> 
>> 
>>> Am 02.01.2018 um 01:37 schrieb Gary Gregory:
>>> 
>>> Hi All:
>>> 
>>> Now that maven-site-plugin 3.7 is out and fixes building with Java 9, I
>>> propose we release it.
>>> 
>>> Thoughts?
>>> 
>>> Gary
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 

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

Re: [lang] Add a DaemonThreadFactory

[Chas Honton]

I also have one of these. 

+1

Chas

> On Dec 21, 2017, at 7:34 AM, Roger Whitcomb  wrote:
> 
> I have a class almost identical to this in my project, so +1 to this idea.
> 
> ~Roger Whitcomb
> 
> -Original Message-
> From: Gary Gregory [mailto:garydgreg...@gmail.com] 
> Sent: Tuesday, December 19, 2017 8:27 AM
> To: Commons Developers List 
> Subject: [lang] Add a DaemonThreadFactory
> 
> I keep on copying this from project to project and it seems fitting for 
> Commons Lang:
> 
> import java.util.concurrent.ThreadFactory;
> import java.util.concurrent.atomic.AtomicLong;
> 
> public final class DaemonThreadFactory implements ThreadFactory {
> 
>private final static AtomicLong COUNT = new AtomicLong(1);
> 
>private final String name;
> 
>public DaemonThreadFactory(final String name) {
>super();
>this.name = name;
>}
> 
>@Override
>public Thread newThread(final Runnable r) {
>final Thread thread = new Thread(r, name + " " + 
> COUNT.getAndIncrement());
>thread.setDaemon(true);
>return thread;
>}
> 
> }
> 
> Thoughts?
> 
> Gary
> B‹CB•È[œÝXœØÜšX™KK[XZ[ˆ]‹][œÝXœØÜšX™PÛÛ[[ۜ˘\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ËK[XZ[ˆ]‹Z[ÛÛ[[ۜ˘\XÚK›Ü™ÃB

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

Re: [build-plugin] Re-engineering/release streamlining

[Chas Honton]

Take a look at how the maven team votes and publishes

Chas

> On Nov 11, 2017, at 8:26 PM, Matt Benson  wrote:
> 
> On Nov 11, 2017 9:32 PM, "Rob Tompkins"  wrote:
> 
> 
> 
>>> On Nov 11, 2017, at 10:24 PM, Gary Gregory  wrote:
>>> 
>>> On Sat, Nov 11, 2017 at 8:19 PM, Rob Tompkins  wrote:
>>> 
>>> Hello all,
>>> 
>>> I was wondering if we might think about a 2.X line in the [build-plugin]
>>> to better facilitate our release mechanics so that we don’t have to jump
>>> through all of these hoops that we do when building a release candidate?
>>> 
>>> Steps:
>>> 1. Move the commons-build-plugin to git.
>>> 
>> 
>> +1
>> 
>> 
>>> 2. Fully rewrite it so that it retains its site/github templating, but
>>> adds functionality to perform our releases in git (maybe withholding svn
> on
>>> purpose to incentivize moving repositories to git).
>>> 
>>> Thoughts?
>>> 
>> 
>> I agree, it's a pain. I wonder if we should step back first and see if we
>> can simplify our release requirements. For example, I find it a huge pain
>> that we have to release to both Nexus and the dist folder. I wonder if we
>> could get away with putting ALL we need in Nexus. After it's all on Apache
>> infra...
>> 
> 
> 
> I'm going to go out on a limb and say this won't fly. BUT there is no
> reason we can't script all this kind of stuff to our hearts' content.
> 
> Matt
> 
> 
> Sure. What’s the process for changing the requirements? Proposal...vote? I
> can try to work from the existent requirements, trim some fat, and bring it
> back for edits.
> 
> -Rob
> 
>> Gary
>> 
>> 
>>> 
>>> Cheers,
>>> -Rob
>>> 
>>> 
>>> 
>>> -
>>> 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: [2/2] [lang] remove unused bcel test dependency

[Chas Honton]

You can use dependency:analyze to find used and undeclared or unused and 
declared dependencies.  Perhaps we should add dependency:analyze-only to 
release profile of parent pom to make sure dependencies are clean. 

Chas

> On Oct 14, 2017, at 9:56 AM, Gary Gregory  wrote:
> 
> boom! :-)
> 
> too bad Checkstyle does not do that for you!
> 
> Gary
> 
>> On Oct 14, 2017 10:54, "Benedikt Ritter"  wrote:
>> 
>> Nice one!
>> 
>>  schrieb am Sa. 14. Okt. 2017 um 15:27:
>> 
>>> remove unused bcel test dependency
>>> 
>>> 
>>> Project: http://git-wip-us.apache.org/repos/asf/commons-lang/repo
>>> Commit: http://git-wip-us.apache.org/repos/asf/commons-lang/commit/
>>> 66226ec1
>>> Tree: http://git-wip-us.apache.org/repos/asf/commons-lang/tree/66226ec1
>>> Diff: http://git-wip-us.apache.org/repos/asf/commons-lang/diff/66226ec1
>>> 
>>> Branch: refs/heads/master
>>> Commit: 66226ec1c2ff33e138189463001c649dbb404f56
>>> Parents: 2a8187f
>>> Author: pascalschumacher 
>>> Authored: Sat Oct 14 15:27:27 2017 +0200
>>> Committer: pascalschumacher 
>>> Committed: Sat Oct 14 15:27:27 2017 +0200
>>> 
>>> --
>>> pom.xml | 7 ---
>>> 1 file changed, 7 deletions(-)
>>> --
>>> 
>>> 
>>> http://git-wip-us.apache.org/repos/asf/commons-lang/blob/66226ec1/pom.xml
>>> --
>>> diff --git a/pom.xml b/pom.xml
>>> index 6ba161e..6db828a 100644
>>> --- a/pom.xml
>>> +++ b/pom.xml
>>> @@ -523,13 +523,6 @@
>>> 
>>> 
>>> 
>>> -  org.apache.bcel
>>> -  bcel
>>> -  6.0
>>> -  test
>>> -
>>> -
>>> -
>>>   org.easymock
>>>   easymock
>>>   3.5
>>> 
>>> 


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

Re: [CANCEL][VOTE] Release Apache Commons IO 2.6 based on RC2

[Chas Honton]

Jacoco code coverage does runtime instrumentation, so this would not happen 
with Jacoco profile. 

Chas

> On Oct 15, 2017, at 2:45 AM, Benedikt Ritter  wrote:
> 
> Hello,
> 
>> Am 14.10.2017 um 14:35 schrieb Benedikt Ritter :
>> 
>> Hello,
>> 
>> we have fixed quite a few bugs and added some nice new features since Apache 
>> Commons IO 2.5 was released, so I would like to release Apache Commons IO 
>> 2.6 based on RC2.
>> 
>> The changes since RC1 are:
>> - Worked on the design of the ByteOrderParser class
>> - Fixed IO-546
>> - Fixed IO-553
>> 
>> Commons IO 2.6 RC1 is available for review here: 
>> https://dist.apache.org/repos/dist/dev/commons/io/commons-io-2.6-RC2 (svn 
>> revision 22474)
>> 
>> The tag is here: 
>> https://git-wip-us.apache.org/repos/asf?p=commons-io.git;a=tag;h=dbd097debffe1b8c91d232a2311c08ff3e70e7a1
>> 
>> Commit ID the tag points at: a219081780bb1714876ef3e1109283b96f3b007b
>> 
>> Maven Artifacts: 
>> https://repository.apache.org/content/repositories/orgapachecommons-1276
>> 
>> These are the Maven artifacts and their hashes:
>> 
>> /commons-io/commons-io/2.6/commons-io-2.6-test-sources.jar.asc
>> (SHA1: 2a6e16c3f135851b5a907bd50655db9f9bff73a2)
>> /commons-io/commons-io/2.6/commons-io-2.6.pom.asc
>> (SHA1: 177e5b7e423cb9747f5b3cb982af326d24698c64)
>> /commons-io/commons-io/2.6/commons-io-2.6-tests.jar.asc
>> (SHA1: 38ccc2062ed998df95910eda9982e5c9623eb8cc)
>> /commons-io/commons-io/2.6/commons-io-2.6.pom
>> (SHA1: 5060835593e5b6ed18c82fc2e782f0a3c30a00b1)
>> /commons-io/commons-io/2.6/commons-io-2.6.jar.asc
>> (SHA1: 7a389502e94871e30f3330634925dff61e4e098a)
>> /commons-io/commons-io/2.6/commons-io-2.6-test-sources.jar
>> (SHA1: 75c8aa60dc4623dca0311b38f317ba56596a70ec)
>> /commons-io/commons-io/2.6/commons-io-2.6-javadoc.jar
>> (SHA1: 2d1132e48d5d2b698cc27290758dca7905031cfa)
>> /commons-io/commons-io/2.6/commons-io-2.6-sources.jar
>> (SHA1: db473f690e219b0566e7f1a8a991bf0e6f08a3c6)
>> /commons-io/commons-io/2.6/commons-io-2.6-tests.jar
>> (SHA1: 02a08a358025f15d44b5f04410d89b413b97)
>> /commons-io/commons-io/2.6/commons-io-2.6.jar
>> (SHA1: adac173d974250643940c7836caf2726f11a0dc0)
>> /commons-io/commons-io/2.6/commons-io-2.6-javadoc.jar.asc
>> (SHA1: 7d78d02ce0d96c511de696b518f1c12133662417)
>> /commons-io/commons-io/2.6/commons-io-2.6-sources.jar.asc
>> (SHA1: 8debf732bc0e5187432f723c01503d75145dbd19)
>> 
>> I have tested this with JDK 8 using Maven 3.5.0.
>> 
>> Details of changes since 2.5 are in the release notes:
>> https://dist.apache.org/repos/dist/dev/commons/io/commons-io-2.6-RC2/RELEASE-NOTES.txt
>> http://home.apache.org/~britter/commons/commons-io-2.6-RC2/changes-report.html
>> 
>> I’ve already realized that I messed up the changes.xml: It has the wrong 
>> release date. I think we can fix this after the release since it is used to 
>> generate the website.
>> 
>> Site:
>> http://home.apache.org/~britter/commons/commons-io-2.6-RC2/ 
>> (note some *relative* links are broken and the 2.6 directories are not yet 
>> created - these will be OK once the site is deployed)
>> 
>> Clirr Report (compared to 2.5):
>> http://home.apache.org/~britter/commons/commons-io-2.6-RC2//clirr-report.html
>> 
>> RAT Report:
>> http://home.apache.org/~britter/commons/commons-io-2.6-RC2/rat-report.html
>> 
>> KEYS:
>> https://www.apache.org/dist/commons/KEYS
>> 
>> Please review the release candidate and vote. This vote will close no sooner 
>> that 72 hours from now, i.e. sometime after 15:00 CEST (UTC+2) 17-October 
>> 2017
>> 
>> [ ] +1 Release these artifacts
>> [ ] +0 OK, but…
>> [ ] -0 OK, but really should fix…
>> [ ] -1 I oppose this release because…
> 
> This vote is canceled because the binary distribution contains cobertura 
> instrumented class files.
> 
> I will work on RC3 now.
> 
> Thank you!
> Benedikt
> 
>> 
>> Thanks!
>> 
>> Benedikt  
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 


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

Re: [ALL] Automated requirements (e.g. CheckStyle)?

[Chas Honton]

Since most of us work in an IDE, the "wasted" time of checkstyle for every 
build is negligible. At my day job, all code is automatically reformatted as 
part of the build. It's just another step along with PMD, CPD, findbugs, sonar, 
jacoco, junit, and a few other static analyses. The more we automate, the less 
we need to remember and the higher the quality of our code. 

Chas

> On Aug 8, 2017, at 4:13 PM, Gilles  wrote:
> 
> Hello.
> 
>> On Wed, 9 Aug 2017 00:20:00 +0200, Karl-Philipp Richter wrote:
>> Hi,
>> 
>>> Am 07.08.2017 um 15:09 schrieb Gilles:
>>> Less work for the maintainers is good. :-)
>>> 
>>> By "taking time" I meant that validating should not be enforced when
>>> calling "mvn compile" or "mvn test".
>> I wouldn't worry about the time consumption of the validation even if
>> it's run by every dev before very compilation since the sum of
>> conversation parts in patch/PR discussion in the form of "LGTM, except
>> for the indentation at line xy" - "OK, I fixed that now" - "Oh, no wait,
>> I forgot the trailing space at line yz" - ... - merged takes an infinite
>> more of time and energy.
> 
> I agree, but that is with respect to interaction with someone not used
> to the coding style/rules; what I meant is that when doing one's "own"
> work, one shouldn't have to wait for CheckStyle at every compilation,
> when you know that you'll fix the missing doc _after_ fixing the code.
> 
>> Regarding the phase where checkstyle should be run I have some
>> additional thoughts to my initial post:
>> 
>>  * If running checkstyle will be enforced the only phase that makes
>> sense is `validate` because you don't won't to build something that's
>> invalid because it's somehow unlogical and a waiste of time if you don't
>> fail the build as early as possible. In order to avoid annoyance for
>> users who aren't used to fix checkstyle errors before being able to
>> build I'd suggest a profile with deactivated checkstyle which allows
>> that rather an putting checkstyle in a separate profile.
> 
> IIUC, that would be fine (since it takes care of the above scenario).
> 
>>  * Running checkstyle in the site or any other reporting phase is in
>> Maven speak afaik "show what might be wrong with my build given the fact
>> that I consider it passing after compilation, unit and integration tests
>> passed" or "show me some statistics about style issues - 150, wow that's
>> 12 less than last build".
> 
> That's what we've done up to now; and the number of errors is supposed
> to be zero before a release.  But I agree that the risk of a lot of work
> for the RM would be reduced by enforcing checks at least before committing
> to the "master" branch.
> 
> Is anyone objecting?
> 
> I think that the profile should be defined in the "parent" POM.
> Can someone make the necessary additions?
> 
> Thanks,
> Gilles
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 


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

Re: [lang] - Close java.util.Date related enhancement requests as won't fix?

[Chas Honton]

＋1 to close all

Chas

> On Apr 19, 2017, at 9:18 AM, Emmanuel Bourg  wrote:
> 
>> Le 19/04/2017 à 18:00, Pascal Schumacher a écrit :
>> 
>> What do you think?
> 
> I agree for LANG-1065, this case is covered by the Java 8 API. The
> improvements suggested in the other issues could be designed to work
> with the java.time API, maybe in a dedicated commons-time component.
> 
> Emmanuel Bourg
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 


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

Re: [text] On the value of idempotent string escape methods?

[Chas Honton]

Not sufficiently useful to include in commons. 

Chas

> On Feb 21, 2017, at 1:31 PM, Bhowmik, Bindul  wrote:
> 
>> On Tue, Feb 21, 2017 at 7:55 AM, sebb  wrote:
>>> On 21 February 2017 at 12:40, Rob Tompkins  wrote:
>>> 
 On Feb 21, 2017, at 6:02 AM, sebb  wrote:
 
 On 21 February 2017 at 04:40, Sampanna Kahu > wrote:
> Hi Guys,
> Very good points are being made above. Please allow me to add my two cents
> :-)
> 
> What if the string contains syntactically valid HTML characters/tags and
> our aim is to prevent rendering these tags in the browser when this string
> is being served via a web application? Or prevent the execution of harmful
> embedded scripts when serving it? The 'escapeOnce' method could be useful
> here, right?
 
 I don't think so.
 
> To explain better, let's consider an example of the specific use-case that
> I had in mind when building the 'escapeOnce' method:
> Consider the scenario of a simple restful web application where users can
> manipulate their text using simple crud operations. Lets assume that we do
> not have the 'escapeOnce' method yet.
> 1. A user comes and submits his string. We escape it and store it in our
> database. If the string had any HTML characters, they would have gotten
> escaped.
> 
> 2. After some time, the same user fetches his string, adds some more HTML
> characters and submits it. At this point, although the escape method would
> correctly escape the freshly added HTML characters, it would escape the
> older escaped HTML characters again! (for example  would become
> gt;)
> And this effect gets magnified if step number 2 above is repeated.
 
 Of course, that is my point.
 
 Also remember that you want to show the original string to the user.
 That's not possible in general if you use this approach.
 
 Suppose they originally entered
 
 "To code ampersand (&) in HTML, use ''"
 
 Using escapeOnce, this would become:
 
 "To code ampersand () in HTML, use ''"
 
 You can either show that directly to the user, or use an unescapeOnce
 and show them:
 
 "To code ampersand (&) in HTML, use '&'"
> 
> I have had this use case in a project (enclosing XML/HTML content in a
> XML stream) and the expected output for escapeOnce in this case would
> be:
> "To code ampersand () in HTML, use 'amp;'"
> 
> And similarly unsecape once would generate back:
> "To code ampersand (&) in HTML, use ''"
> 
> Just my two cents, as I have had to write this code.
> 
 
 Neither makes any sense.
 
> How do we solve the above problem without the 'escapeOnce' method?
 
 Store the raw string in the database and escape it just before display.
 
 If you are using Javascript, then use an approach such as this to escape 
 it:
 
 document.getElementById("whereItGoes").appendChild(document.createTextNode(unsafe_str));
 
 See:
 
 http://shebang.brandonmintern.com/foolproof-html-escaping-in-javascript/ 
 
 
 This has a good discussion of some of the problems.
 
 ==
 
 Sorry, but it's not possible in general to do what you want, because
 one cannot reliably determine if a string has been escaped just from
 looking at the string.
>>> 
>>> Another thought occurred to me (again despite potential lack of value).
>>> 
>>> We should be able to quickly verify if there are any escape strings in the 
>>> string in question. A single application of unescape followed by checking 
>>> string equality with the original input would yield a predicate on the 
>>> existence of escape’s present in the input in question.
>> 
>> Again, what does unescape mean in this context?
>> Does it ignore incomplete escape sequences, or throw an error?
>> 
>>> From there we could: (1) escape if no escapes were present in the original, 
>>> or (2) throw an exception if there were escapes present in the original 
>>> string.
>>> Again, this feels contrived, so I’m not really suggesting that we add it. 
>>> I’m just playing with ideas here that could accomplish what Sampanna is 
>>> going for.
>> 
>> The request is impossible to fulfill reliably, and does not deserve to
>> be added to a Commons library.
>> 
>> I don't know why this is still being discussed.
>> 
>>> -Rob
>>> 
 
 The most one can do is to sanitise the string by escaping anything
 that is unescaped.
 However that process corrupts the input - a browser won't display the
 proper output.
 
>> On 20 February 2017 at 21:40, sebb  wrote:
>> 
>>> On 20 February 2017 at 15:36, Rob Tompkins  wrote:
>>> 
 

Re: [ALL] hashes of signatures

[Chas Honton]

There was an update in parent to prevent excess jars from being attached as 
artifacts. 

https://svn.apache.org/viewvc/view=revision=1755904


I don't believe it's been released. 

Chas

> On Oct 31, 2016, at 9:53 AM, Matt Benson  wrote:
> 
> Thanks for repying, but that seems backward: signatures of hashes. I'm
> talking about ending up with *.jar.asc.md5 and *.jar.asc.sha1 . :)
> 
> Matt
> 
> On Mon, Oct 31, 2016 at 11:32 AM, Stian Soiland-Reyes 
> wrote:
> 
>> In Commons RDF we used this:
>> 
>>
>>
>>   
>>org.apache.maven.plugins
>>maven-gpg-plugin
>>
>>
>>**/*.asc
>>**/*.md5
>>**/*.sha1
>>
>>
>>
>>
>> 
>> is that sufficient in Bval?  If so we can add it to commons-parent.
>> 
>> 
>> 
>>> On 31 October 2016 at 15:58, Matt Benson  wrote:
>>> The release procedures mention the problem of these extraneous files in
>> the
>>> Nexus staging repo. I have noticed during the last couple of [weaver]
>>> release cycles that these files no longer show up and had thought it was
>>> something they had fixed on Nexus. Then I rolled a vote candidate for
>>> Apache BVal and find the files are there on the staging repo. Is anyone
>>> aware of having fixed this issue in the Commons build? I can't find any
>>> config that seems relevant.
>>> 
>>> Thanks,
>>> Matt
>> 
>> 
>> 
>> --
>> Stian Soiland-Reyes
>> http://orcid.org/-0001-9842-9718
>> 
>> -
>> 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] Release commons-parent 41 based on RC2

[Chas Honton]

No votes.  Will work on release tonight. 

Chas

> On Aug 10, 2016, at 9:27 AM, Gary Gregory  wrote:
> 
> Has this vote been tabulated?
> 
> Gary
> 
>> On Wed, Aug 3, 2016 at 9:17 PM, Charles Honton  wrote:
>> 
>> We have added a significant enhancements since commons-parent 40 was
>> released,
>> so I would like to release commons-parent 41.
>> 
>> commons-parent 41 RC2 is available for review here:
>>https://dist.apache.org/repos/dist/dev/commons/commons-
>> parent/commons-parent-41-RC2 (svn revision 14654)
>> 
>> The tag is here:
>>https://svn.apache.org/repos/asf/commons/proper/commons-
>> parent/tags/commons-parent-41-RC2/ (svn revision 1755138)
>> 
>> Maven artifacts are here:
>>https://repository.apache.org/content/repositories/
>> orgapachecommons-1195/org/apache/commons/commons-parent/41/
>> 
>> These are the Maven artifacts and their hashes
>> 
>> commons-parent-41.pom
>> (SHA1: c88f7453ccb914ba5de83e0557456fadf6db4022)
>> 
>> I have tested this with JDK 1.6, 7  using Maven 3.3.9
>> 
>> Details of changes since 1.1 are in the release notes:
>>https://svn.apache.org/repos/asf/commons/proper/commons-
>> parent/tags/commons-parent-41-RC2/RELEASE-NOTES.txt
>>https://people.apache.org/~chas/commons-parent-41-RC2/
>> changes-report.html
>> 
>> Site:
>>https://people.apache.org/~chas/commons-parent-41-RC2
>> 
>>  (note some *relative* links are broken and the 41 directories are not
>> yet created - these will be OK once the site is deployed)
>> http://commons.apache.org/commons-parent-pom.html will be updated after
>> release with additional profile details.
>> 
>> KEYS:
>>  https://www.apache.org/dist/commons/KEYS
>> 
>> Please review the release candidate and vote.  This is a LAZY vote.
>> This vote will close no sooner that 72 hours from now,
>> i.e. sometime after 2016-08-07T05:00Z
>> 
>>  [ ] +1 Release these artifacts
>>  [ ] -1 I oppose this release because...
>> 
>> chas
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

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

Re: [RESULT][VOTE] Release Apache Commons BCEL 6.0 based on RC8

[Chas Honton]

Congratulations!

Chas

> On Jul 14, 2016, at 12:42 AM, Benedikt Ritter  wrote:
> 
> This vote passes (am I dreaming? ;-) The following votes were cast:
> 
> Oliver Heger: +1 (binding)
> Gary Gregory: +1 (binding)
> Mark Roberts: +1
> Oliver Lamy: +1 (binding)
> Jörg Schaible: +1 (binding)
> Emmanuel Bourg: +1 (binding)
> Benedikt Ritter: +1 (binding)
> 
> Thank you for reviewing this RC and the one before.
> 
> Benedikt
> 
> Benedikt Ritter  schrieb am So., 10. Juli 2016 um
> 22:57 Uhr:
> 
>> Hi all,
>> 
>> hopefully the final RC for releasing Apache Commons BCEL 6.0 :-) Changes
>> since RC7:
>> 
>> - fixed failing build on Windows plattforms
>> - corrected fix for BCEL-262
>> 
>> Apache Commons BCEL 6.0 is available for review here:
>>  https://dist.apache.org/repos/dist/dev/commons/bcel (rev 14344)
>> 
>> The tag is here:
>>  https://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_RC8
>> (rev 1752118)
>> 
>> Maven artifacts:
>> 
>> https://repository.apache.org/content/repositories/orgapachecommons-1183/org/apache/bcel/bcel/6.0/
>> 
>> Maven artifact hashes:
>> 
>> bcel-6.0-test-sources.jar
>> (SHA1: 30ba969d603b676929b69228ad0f2a4fc1c9c830)
>> bcel-6.0.pom
>> (SHA1: aff6c560d92df15a207247c5b0293bb734389094)
>> bcel-6.0.jar
>> (SHA1: 7d08bcac4832f81467d3e2ca5bd58ad627288656)
>> bcel-6.0-tests.jar
>> (SHA1: 3536d25398f6f6ac22deb9e446515056191661f7)
>> bcel-6.0-javadoc.jar
>> (SHA1: e47a109aa7416329a9970f0900136cb355af8ac8)
>> bcel-6.0-sources.jar
>> (SHA1: 206dfd32271b9b0150d8211070e5dbbe69cf5154)
>> 
>> I've tested with Java 7 & 8 using Maven 3.3.9
>> 
>> Details of changes since 5.2 are in the release notes:
>>  https://dist.apache.org/repos/dist/dev/commons/bcel//RELEASE-NOTES.txt
>>  http://home.apache.org/~britter/commons/bcel/6.0-RC8/changes-report.html
>> 
>> Site:
>>  http://home.apache.org/~britter/commons/bcel/6.0-RC8
>> (note some *relative* links are broken and the 6.0 directories are not yet
>> created - these will be OK once the site is deployed)
>> 
>> Clirr Report (compared to 5.2):
>>  http://home.apache.org/~britter/commons/bcel/6.0-RC8/clirr-report.html
>> 
>> Note that Clirr reports several errors.
>> These are considered OK for the reasons stated below.
>> These exceptions are also noted in the Changes and Release Notes.
>> 
>> Errors reported:
>> - methods added to org.apache.bcel.classfile.Visitor interface: OK
>> because that does not affect binary compatibility.
>> - Removed java.io.Serializable from all classes: OK, because we don't
>> expect anybody to rely on serialization for BCEL classes
>> - Return type of method 'public java.lang.Object getElementAt(int)' has
>> been changed to java.lang.String in class 
>> org.apache.bcel.verifier.VerifierFactoryListModel:
>> OK, because this class is part of an UI application and for this reason
>> should only used by Swing.
>> 
>> RAT Report:
>>  http://home.apache.org/~britter/commons/bcel/6.0-RC8/rat-report.html
>> 
>> KEYS:
>>  https://www.apache.org/dist/commons/KEYS
>> 
>> Please review the release candidate and vote. This vote will close no
>> sooner that 72 hours from now, i.e. sometime after 23:00 CEST 13-July 2016
>> 
>> [ ] +1 Release these artifacts
>> [ ] +0 OK, but...
>> [ ] -0 OK, but really should fix...
>> [ ] -1 I oppose this release because...
>> 
>> Thank you!
>> Benedikt
>> 
>> 


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

Re: [LANG] Failing tests

[Chas Honton]

The line number makes it look like the  Parameterized values are not being 
properly set by junit. Is it possible that we're using a new parent Pom that 
doesn't fully configure junit plugin version?  What version of maven are you 
using?

I just successfully built from tip on a Mac using maven 3.3.9 and Java 
1.8.0_92. 

Chas

> On May 1, 2016, at 12:20 PM, sebb  wrote:
> 
>> On 1 May 2016 at 19:32, Benedikt Ritter  wrote:
>> Hi,
>> 
>> when building a clean checkout of Commons LANG, I get a lot of failing
>> tests:
> 
> OS?
> Java?
> 
>> Tests in error:
>>  FastDateFormat_ParserTest>FastDateParserTest.testTzParses:265 »
>> NullPointer
>>  FastDateParserSDFTest.testLowerCasePP:149->checkParsePosition:195 »
>> NullPointer
>>  FastDateParserSDFTest.testLowerCasePP:149->checkParsePosition:195 »
>> NullPointer
>>  FastDateParserSDFTest.testLowerCasePP:149->checkParsePosition:195 »
>> NullPointer
>>  FastDateParserSDFTest.testLowerCasePP:149->checkParsePosition:195 »
>> NullPointer
>>  FastDateParserSDFTest.testLowerCasePP:149->checkParsePosition:195 »
>> NullPointer
>>  FastDateParserSDFTest.testLowerCasePP:149->checkParsePosition:195 »
>> NullPointer
>>  FastDateParserSDFTest.testLowerCasePP:149->checkParsePosition:195 »
>> NullPointer
>>  FastDateParserSDFTest.testLowerCasePP:149->checkParsePosition:195 »
>> NullPointer
>>  FastDateParserSDFTest.testLowerCase:144->checkParse:155 » NullPointer
>>  FastDateParserSDFTest.testLowerCase:144->checkParse:155 » NullPointer
>>  FastDateParserSDFTest.testLowerCase:144->checkParse:155 » NullPointer
>>  FastDateParserSDFTest.testLowerCase:144->checkParse:155 » NullPointer
>>  FastDateParserSDFTest.testLowerCase:144->checkParse:155 » NullPointer
>>  FastDateParserSDFTest.testLowerCase:144->checkParse:155 » NullPointer
>>  FastDateParserSDFTest.testLowerCase:144->checkParse:155 » NullPointer
>>  FastDateParserSDFTest.testLowerCase:144->checkParse:155 » NullPointer
>>  FastDateParserSDFTest.testOriginalPP:129->checkParsePosition:195 »
>> NullPointer
>>  FastDateParserSDFTest.testOriginalPP:129->checkParsePosition:195 »
>> NullPointer
>>  FastDateParserSDFTest.testOriginalPP:129->checkParsePosition:195 »
>> NullPointer
>>  FastDateParserSDFTest.testOriginalPP:129->checkParsePosition:195 »
>> NullPointer
>>  FastDateParserSDFTest.testOriginalPP:129->checkParsePosition:195 »
>> NullPointer
>>  FastDateParserSDFTest.testOriginalPP:129->checkParsePosition:195 »
>> NullPointer
>>  FastDateParserSDFTest.testOriginalPP:129->checkParsePosition:195 »
>> NullPointer
>>  FastDateParserSDFTest.testOriginalPP:129->checkParsePosition:195 »
>> NullPointer
>>  FastDateParserSDFTest.testOriginal:124->checkParse:155 » NullPointer
>>  FastDateParserSDFTest.testOriginal:124->checkParse:155 » NullPointer
>>  FastDateParserSDFTest.testOriginal:124->checkParse:155 » NullPointer
>>  FastDateParserSDFTest.testOriginal:124->checkParse:155 » NullPointer
>>  FastDateParserSDFTest.testOriginal:124->checkParse:155 » NullPointer
>>  FastDateParserSDFTest.testOriginal:124->checkParse:155 » NullPointer
>>  FastDateParserSDFTest.testOriginal:124->checkParse:155 » NullPointer
>>  FastDateParserSDFTest.testOriginal:124->checkParse:155 » NullPointer
>>  FastDateParserSDFTest.testUpperCasePP:139->checkParsePosition:195 »
>> NullPointer
>>  FastDateParserSDFTest.testUpperCasePP:139->checkParsePosition:195 »
>> NullPointer
>>  FastDateParserSDFTest.testUpperCasePP:139->checkParsePosition:195 »
>> NullPointer
>>  FastDateParserSDFTest.testUpperCasePP:139->checkParsePosition:195 »
>> NullPointer
>>  FastDateParserSDFTest.testUpperCasePP:139->checkParsePosition:195 »
>> NullPointer
>>  FastDateParserSDFTest.testUpperCasePP:139->checkParsePosition:195 »
>> NullPointer
>>  FastDateParserSDFTest.testUpperCasePP:139->checkParsePosition:195 »
>> NullPointer
>>  FastDateParserSDFTest.testUpperCasePP:139->checkParsePosition:195 »
>> NullPointer
>>  FastDateParserSDFTest.testUpperCase:134->checkParse:155 » NullPointer
>>  FastDateParserSDFTest.testUpperCase:134->checkParse:155 » NullPointer
>>  FastDateParserSDFTest.testUpperCase:134->checkParse:155 » NullPointer
>>  FastDateParserSDFTest.testUpperCase:134->checkParse:155 » NullPointer
>>  FastDateParserSDFTest.testUpperCase:134->checkParse:155 » NullPointer
>>  FastDateParserSDFTest.testUpperCase:134->checkParse:155 » NullPointer
>>  FastDateParserSDFTest.testUpperCase:134->checkParse:155 » NullPointer
>>  FastDateParserSDFTest.testUpperCase:134->checkParse:155 » NullPointer
>>  FastDateParserTest.testTzParses:265 » NullPointer
>>  FastDateParser_TimeZoneStrategyTest.testTimeZoneStrategyPattern:33 »
>> NullPointer
>> 
>> Tests run: 3802, Failures: 0, Errors: 51, Skipped: 5
>> 
>> Any idea about this?
>> 
>> Benedikt
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

Re: [math] Name of the new TLP

[Chas Honton]

Using the list from https://en.m.wikipedia.org/wiki/Areas_of_mathematics, the 
current commons math appears to be a sub-set of numerical analysis algorithms.  
Is this correct?  Will this continue be the focus of a math tlp? 

Unfortunately, Apache Numerical Analysis does not trip off the tongue. 

Chas

> On Jan 25, 2016, at 9:21 PM, Henri Yandell  wrote:
> 
> Any reason why you're not going with Apache Math - math.apache.org?
> 
> No one is going to wince if you have other language implementations in the
> same project, and if it needs to break up over time because there is Apache
> Math GroupTheory, Apache Math Fluid Dynamics etc etc; then more power to
> y'all.
> 
> Hen
> 
> 
>> On Sun, Jan 24, 2016 at 1:08 PM, Phil Steitz  wrote:
>> 
>> We need to agree on a name.  My own preference is for a boring,
>> descriptive name, but I am manifestly not a marketing guy, so won't
>> be offended if others want to be more creative.
>> 
>> My suggestion is
>> 
>> MathComponents
>> 
>> Hearkens back to HttpComponents, which has worked pretty well.
>> 
>> Phil
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 

Re: svn commit: r1695425 - in /commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6: generic/FieldOrMethod.java verifier/statics/Pass3aVerifier.java verifier/structurals/InstConstraintVisi

[Chas Honton]

Will work in this evening. (GMT-8). 

Chas

> On Sep 9, 2015, at 2:07 AM, sebb  wrote:
> 
> PING
> 
> I am -1 on the commit as it stands; please revert or fix
> 
>> On 28 August 2015 at 01:43, sebb  wrote:
>>> On 12 August 2015 at 07:32,   wrote:
>>> Author: chas
>>> Date: Wed Aug 12 06:32:41 2015
>>> New Revision: 1695425
>>> 
>>> URL: http://svn.apache.org/r1695425
>>> Log:
>>> BCEL-236: remove deprecated FieldOrMethod.getClassType(ConConstantPoolGen)
>> 
>> I think this needs to be reverted or amended.
>> 
>> The new method FieldOrMethod.getLoadClassType(ConstantPoolGen cpg) can
>> throw a ClassCastException.
>> See below.
>> 
>>> Modified:
>>>
>>> commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/generic/FieldOrMethod.java
>>>
>>> commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/verifier/statics/Pass3aVerifier.java
>>>
>>> commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/verifier/structurals/InstConstraintVisitor.java
>>> 
>>> Modified: 
>>> commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/generic/FieldOrMethod.java
>>> URL: 
>>> http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/generic/FieldOrMethod.java?rev=1695425=1695424=1695425=diff
>>> ==
>>> --- 
>>> commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/generic/FieldOrMethod.java
>>>  (original)
>>> +++ 
>>> commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/generic/FieldOrMethod.java
>>>  Wed Aug 12 06:32:41 2015
>>> @@ -95,17 +95,6 @@ public abstract class FieldOrMethod exte
>>> }
>>> 
>>> 
>>> -/** @return type of the referenced class/interface
>>> - * @deprecated If the instruction references an array class,
>>> - *the ObjectType returned will be invalid.  Use
>>> - *getReferenceType() instead.
>>> - */
>>> -@Deprecated
>>> -public ObjectType getClassType( ConstantPoolGen cpg ) {
>>> -return ObjectType.getInstance(getClassName(cpg));
>>> -}
>>> -
>>> -
>>> /**
>>>  * Return the reference type representing the class, interface,
>>>  * or array class referenced by the instruction.
>>> @@ -131,6 +120,6 @@ public abstract class FieldOrMethod exte
>>> /** @return type of the referenced class/interface
>>>  */
>>> public ObjectType getLoadClassType( ConstantPoolGen cpg ) {
>>> -return getClassType(cpg);
>>> +return (ObjectType)getReferenceType(cpg);
>> 
>> ObjectType is not a subclass of ArrayType
>> 
>> It does not seem right to hide the original reason for the deprecation this 
>> way.
>> 
>> The code should at least check the object type and throw a better
>> exception than CCE
>> And the Javadoc should make the pre-condition clear
>> 
>>> }
>>> }
>>> 
>>> Modified: 
>>> commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/verifier/statics/Pass3aVerifier.java
>>> URL: 
>>> http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/verifier/statics/Pass3aVerifier.java?rev=1695425=1695424=1695425=diff
>>> ==
>>> --- 
>>> commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/verifier/statics/Pass3aVerifier.java
>>>  (original)
>>> +++ 
>>> commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/verifier/statics/Pass3aVerifier.java
>>>  Wed Aug 12 06:32:41 2015
>>> @@ -85,6 +85,7 @@ import org.apache.commons.bcel6.generic.
>>> import org.apache.commons.bcel6.generic.ObjectType;
>>> import org.apache.commons.bcel6.generic.PUTSTATIC;
>>> import org.apache.commons.bcel6.generic.RET;
>>> +import org.apache.commons.bcel6.generic.ReferenceType;
>>> import org.apache.commons.bcel6.generic.ReturnInstruction;
>>> import org.apache.commons.bcel6.generic.TABLESWITCH;
>>> import org.apache.commons.bcel6.generic.Type;
>>> @@ -543,6 +544,15 @@ public final class Pass3aVerifier extend
>>> }
>>> }
>>> 
>>> +private ObjectType getObjectType(FieldInstruction o) {
>>> +ReferenceType rt = o.getReferenceType(cpg);
>>> +if(rt instanceof ObjectType) {
>>> +return (ObjectType)rt;
>>> +}
>>> +constraintViolated(o, "expecting ObjectType but got "+rt);
>>> +return null;
>>> +}
>> 
>> Here we see that the code checks the return class, which is fine.
>> 
>>> /** Checks if the constraints of operands of the said 
>>> instruction(s) are satisfied. */
>>>  //getfield, putfield, getstatic, putstatic
>>>  @Override
>>> @@ -555,8 +565,8 @@ public final class Pass3aVerifier extend
>>> }
>>> 
>>> String field_name = o.getFieldName(cpg);
>>> -
>>> -JavaClass jc = 
>>> 

[BCEL] InstructionHandle refactor

[Chas Honton]

I've created a pull request for a major refactor of how InstructionList and 
InstructionHandle work. Please review the contents of 
https://github.com/apache/commons-bcel/pull/2. 

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

Re: [LANG] Time for 3.5?

[Chas Honton]

Benedikt,

Please take a look at mr pull request for FastDateParser. 

Thanks,
Chas

 On Jun 26, 2015, at 4:19 AM, Benedikt Ritter brit...@apache.org wrote:
 
 Hi,
 
 we have a lot of good new stuff, so I'm planning to review pending issues
 over the next weeks and push out the next release until end of July. If
 there's anything you'd like to have included, now is your chance to do it
 :-)
 
 Benedikt
 
 -- 
 http://people.apache.org/~britter/
 http://www.systemoutprintln.de/
 http://twitter.com/BenediktRitter
 http://github.com/britter

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

[Lang] commons-lang pull request: refactor FastDateParser

[Chas Honton]

I just created a pull request for a major refactor of the FastDateParser class. 
I request anyone with org.apache.commons.lang3.time interest and/or experience 
take time to review. 

Thanks,
Chas

Begin forwarded message:

 From: chonton g...@git.apache.org
 Date: June 11, 2015 at 8:19:46 PM PDT
 To: iss...@commons.apache.org
 Subject: [GitHub] commons-lang pull request: refactor FastDateParser
 Reply-To: iss...@commons.apache.org
 Reply-To: iss...@commons.apache.org
 
 GitHub user chonton opened a pull request:
 
https://github.com/apache/commons-lang/pull/96
 
refactor FastDateParser
 
use hashmap for performance
break down regular expressions to per-format, allowing
ParsePosition to get set
add parse with Calendar input, allowing client to set leniency
and/or replace display names
 
 You can merge this pull request into a Git repository by running:
 
$ git pull https://github.com/chonton/commons-lang refactor-fastdateparser
 
 Alternatively you can review and apply these changes as the patch at:
 
https://github.com/apache/commons-lang/pull/96.patch
 
 To close this pull request, make a commit to your master/trunk branch
 with (at least) the following in the commit message:
 
This closes #96
 
 
 commit 94faa31bcf5c4fcb20818a3a0d23ae789932d2df
 Author: Chas Honton c...@apache.org
 Date:   2015-06-12T03:07:13Z
 
refactor FastDateParser
 
use hashmap for performance
break down regular expressions to per-format, allowing
ParsePosition to get set
add parse with Calendar input, allowing client to set leniency
and/or replace display names
 
 
 
 
 ---
 If your project is set up for it, you can reply to this email and have your
 reply appear on GitHub as well. If your project does not have this feature
 enabled and wishes so, or if the feature is enabled but not working, please
 contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
 with INFRA.
 ---

Re: [LANG] Build failing on Travis CI

[Chas Honton]

I will work on this weekend. 

Regards,
Chas

 On May 1, 2015, at 3:07 AM, Benedikt Ritter brit...@apache.org wrote:
 
 Hello Charles,
 
 it looks like your latest fixes have caused a regression (but only on JDK
 6?!) [1]. Do you have time to have a look? Thank you so much for working on
 the time package.
 
 Best regards,
 Benedikt
 
 [1] https://travis-ci.org/apache/commons-lang/builds/60788015
 
 
 -- 
 http://people.apache.org/~britter/
 http://www.systemoutprintln.de/
 http://twitter.com/BenediktRitter
 http://github.com/britter

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

Re: [lang] testTimeZoneStrategyPattern() runs twice for no apparent gain

[Chas Honton]

Duncan,

Nothing lost by moving into separate test class. Speed gained. 

Chas

 On Apr 11, 2015, at 12:02 AM, Duncan Jones dun...@wortharead.com wrote:
 
 Hi everyone,
 
 Lang takes a few minutes to build on my system, so I was examining
 execution times of tests to see if anything can be improved.
 
 I noticed that FastDateParserTest.testTimeZoneStrategyPattern() takes
 quite a long time to execute (over 40 seconds for me). Then I noticed
 this is executed twice, once for FastDateParserTest and once for the
 subclass FastDateFormat_ParserTest. Yet the method doesn't appear to
 use the result of getInstance(). As a result, we don't want this being
 executed by subclasses as it gains us nothing.
 
 Before I refactor this test, possibly into a separate
 TimeZoneStrategyTest class, can anyone suggest a reason not to? Or a
 better solution / location for the test?
 
 Duncan
 
 -
 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: r1671734 - in /commons/proper/lang/trunk/src: changes/ main/java/org/apache/commons/lang3/time/ test/java/org/apache/commons/lang3/reflect/ test/java/org/apache/commons/lang3/time/

[Chas Honton]

Benedikt,

Expletive, I wasn't being careful.  The changes to FieldUtilsTest are to allow 
test to pass under jacoco coverage. 

I will revert, add another JIRA, fix changed.xml, and split into two commits 
tonight. 

Chas

 On Apr 6, 2015, at 11:29 PM, Benedikt Ritter brit...@apache.org wrote:
 
 Hello Charles,
 
 looks like things got missed up. The Log messages takes about LANG-1109,
 but LANG-1107 was added to changes.xml.
 Furthermore there is a change in FieldUtilsTest. How does this relate to
 either of the issues?
 
 Regards,
 Benedikt
 
 2015-04-07 4:40 GMT+02:00 c...@apache.org:
 
 Author: chas
 Date: Tue Apr  7 02:40:49 2015
 New Revision: 1671734
 
 URL: http://svn.apache.org/r1671734
 Log:
 LANG-1109 - Number percentage formatting with fractional digits
 
 Modified:
commons/proper/lang/trunk/src/changes/changes.xml
 
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/time/FastDateParser.java
 
 commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/reflect/FieldUtilsTest.java
 
 commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/time/FastDateParserSDFTest.java
 
 commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/time/FastDateParserTest.java
 
 Modified: commons/proper/lang/trunk/src/changes/changes.xml
 URL:
 http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/changes/changes.xml?rev=1671734r1=1671733r2=1671734view=diff
 
 ==
 --- commons/proper/lang/trunk/src/changes/changes.xml [utf-8] (original)
 +++ commons/proper/lang/trunk/src/changes/changes.xml [utf-8] Tue Apr  7
 02:40:49 2015
 @@ -22,7 +22,7 @@
   body
 
   release version=3.5 date=tba description=tba
 -
 +action issue=LANG-1107 type=update dev=chasFix parsing edge
 cases in FastDateParser/action
   /release
 
   release version=3.4 date=2014-04-06 description=Feature and
 bugfix release
 
 Modified:
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/time/FastDateParser.java
 URL:
 http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/time/FastDateParser.java?rev=1671734r1=1671733r2=1671734view=diff
 
 ==
 ---
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/time/FastDateParser.java
 (original)
 +++
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/time/FastDateParser.java
 Tue Apr  7 02:40:49 2015
 @@ -744,9 +744,13 @@ public class FastDateParser implements D
 /**
  * A strategy that handles a timezone field in the parsing pattern
  */
 -private static class TimeZoneStrategy extends Strategy {
 -
 -private final String validTimeZoneChars;
 +static class TimeZoneStrategy extends Strategy {
 +private static final String RFC_822_TIME_ZONE = [+-]\\d{4};
 +private static final String GMT_OPTION= GMT[+-]\\d{1,2}:\\d{2};
 +// see http://www.iana.org/time-zones and
 http://cldr.unicode.org/translation/timezones
 +static final String TZ_DATABASE=
 (?:\\p{L}[\\p{L}\\p{Mc}\\p{Nd}\\p{Zs}\\p{P}[^-]]*-?\\p{Zs}?)*;
 +private static final String VALID_TZ =
 ((?iu)+RFC_822_TIME_ZONE+|+GMT_OPTION+|+TZ_DATABASE+);
 +
 private final SortedMapString, TimeZone tzNames= new
 TreeMapString, TimeZone(String.CASE_INSENSITIVE_ORDER);
 
 /**
 @@ -777,9 +781,6 @@ public class FastDateParser implements D
 TimeZoneStrategy(final Locale locale) {
 final String[][] zones =
 DateFormatSymbols.getInstance(locale).getZoneStrings();
 for (final String[] zone : zones) {
 -if (zone[ID].startsWith(GMT)) {
 -continue;
 -}
 final TimeZone tz = TimeZone.getTimeZone(zone[ID]);
 if (!tzNames.containsKey(zone[LONG_STD])){
 tzNames.put(zone[LONG_STD], tz);
 @@ -795,16 +796,7 @@ public class FastDateParser implements D
 tzNames.put(zone[SHORT_DST], tz);
 }
 }
 -}
 -
 -final StringBuilder sb= new StringBuilder();
 -sb.append((GMT[+-]\\d{1,2}:\\d{2}).append('|');
 -sb.append([+-]\\d{4}).append('|');
 -for(final String id : tzNames.keySet()) {
 -escapeRegex(sb, id, false).append('|');
 -}
 -sb.setCharAt(sb.length()-1, ')');
 -validTimeZoneChars= sb.toString();
 +}
 }
 
 /**
 @@ -812,7 +804,7 @@ public class FastDateParser implements D
  */
 @Override
 boolean addRegex(final FastDateParser parser, final StringBuilder
 regex) {
 -regex.append(validTimeZoneChars);
 +regex.append(VALID_TZ);
 return true;
 }
 
 @@ -825,8 +817,8 @@ public class FastDateParser implements D
 

Re: [VOTE] Release Apache Commons Lang 3.4 based on RC2

[Chas Honton]

I have changes which will get tests to pass. Any preference to whether they 
should be added to 3.4 or 3.5?

Chas

 On Apr 4, 2015, at 5:01 AM, Benedikt Ritter brit...@apache.org wrote:
 
 2015-04-04 10:57 GMT+02:00 Duncan Jones djo...@apache.org:
 
 +0 (non-binding)
 
 Built from zipped sources, digests look fine. JDK 1.8.0_40 on Win 8.1.
 (Site build fails as mentioned already).
 Site builds fine from JDK 1.7.0_75. For me the FindBugs page is blank,
 not sure if that's to be expected?
 
 97 skipped tests seems a little high (think this was mentioned on the
 previous vote). FastDateParserSDFTest has 92 of them, although looking
 at the source I see there are two @Ignore-ed tests (and 46 parameter
 values), which explains it. I'd prefer we remove those tests (or
 comment them out), but it's not a big problem.
 
 Sorry, I forgot to mention in the vote mail, that I've also investigated
 this issue. I've already created a JIRA issue for fixing this [1] and it
 looks like Charles already started working on it.
 
 Benedikt
 
 [1] https://issues.apache.org/jira/browse/LANG-1107
 
 
 
 Thanks for taking the effort to be RM, again.
 
 Duncan
 
 
 On 4 April 2015 at 09:12, Sergio Fernández wik...@apache.org wrote:
 +1 (non-binding)
 
 So far I've checked: signatures and digests. source release file layout,
 matched tags and commit ids, NOTICE and LICENSE files, build sources in a
 clean environment (maven 3.0.5, jdks 7u71-2.5.3 and 8.0_25, under debian
 64bits)
 
 
 On Fri, Apr 3, 2015 at 2:56 PM, Benedikt Ritter brit...@apache.org
 wrote:
 
 Hi all,
 
 We've worked through the issues identified in Commons Lang 3.4 RC1, so I
 would like to call a vote for releasing Commons Lang 3.4 based on RC2.
 
 The changes since RC1 are:
 - Fixed TimeZone related problem in test cases
 - Fixed broken windows OS detection in SystemUtils
 - Added OS X support to SystemUtils
 - Fixed Ant build
 - Added compatibility section to release notes explaining the change to
 the
 org.apache.commons.lang3.time.DurationFormatUtils.ISO_EXTENDED_FORMAT_PATTERN
 constant
 
 Commons Lang 3.4 RC2 is available for review here:
  https://dist.apache.org/repos/dist/dev/commons/lang/ (svn revision
 8515)
 
 Maven artifacts are here:
 https://repository.apache.org/content/repositories/orgapachecommons-1086/org/apache/commons/commons-lang3/3.4/
 
 
 Details of changes since 3.3.2 are in the release notes:
  https://dist.apache.org/repos/dist/dev/commons/lang/RELEASE-NOTES.txt
  http://people.apache.org/~britter/lang-3.4-RC2/changes-report.html
 
 I have tested this with JDK 1.6, 1.7, 1.8 and 1.9 EA using maven 3. Note
 that the site build doesn't work with Java 8 and 9 due to problems with
 Clirr (clirr doesn't work with Java 8+).
 
 The tag is here:
 http://svn.apache.org/repos/asf/commons/proper/lang/tags/LANG_3_4_RC2/
 (svn
 1671054)
 
 Site:
  http://people.apache.org/~britter/lang-3.4-RC2/
  (note some *relative* links are broken and the 3.4 directories are not
 yet created - these will be OK once the site is deployed)
 
 Clirr Report (compared to 3.3.2):
  http://people.apache.org/~britter/lang-3.4-RC2/clirr-report.html
 
 RAT Report:
  http://people.apache.org/~britter/lang-3.4-RC2/rat-report.html
 
 KEYS:
  https://www.apache.org/dist/commons/KEYS
 
 Please review the release candidate and vote. This vote will close no
 sooner that 72 hours from now, i.e. after 15:00 CET 06-April 2015
 
 [ ] +1 Release these artifacts
 [ ] +0 OK, but...
 [ ] -0 OK, but really should fix...
 [ ] -1 I oppose this release because...
 
 Thanks!
 
 Benedikt
 
 --
 http://people.apache.org/~britter/
 http://www.systemoutprintln.de/
 http://twitter.com/BenediktRitter
 http://github.com/britter
 
 
 
 --
 Sergio Fernández
 Partner Technology Manager
 Redlink GmbH
 m: +43 6602747925
 e: sergio.fernan...@redlink.co
 w: http://redlink.co
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org
 
 
 -- 
 http://people.apache.org/~britter/
 http://www.systemoutprintln.de/
 http://twitter.com/BenediktRitter
 http://github.com/britter

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