Re: commons-io git commit: Remove redundant type arguments.

[Kristian Rosenvold]

Adding .gitattributes just ensures any future changes will be correct. If
there are committed files with incorrect line endings in the repo they will
not be automatically be fixed. I fixed the remaining incorrect files
in 9e2b2c09732ca596331f7ca34ba4e0f03d70093d.

Kristian


2016-09-22 8:30 GMT+02:00 Benedikt Ritter :

> Gary Gregory  schrieb am Mi., 21. Sep. 2016 um
> 18:57 Uhr:
>
> > My git config --global core.autocrlf is already true... could the file in
> > Git have been stored with Windows EOLs?
> >
>
> Don't know. Looks like Kristian has fixed it via .gitattributes.
>
>
> >
> > Gary
> >
> >
> >
> > On Wed, Sep 21, 2016 at 2:05 AM, Benedikt Ritter 
> > wrote:
> >
> > > Hi Gary,
> > >
> > > is you line ending set up correct? See
> > > https://help.github.com/articles/dealing-with-line-endings/
> > >
> > > Can you please revert the commit and then commit only the stuff you
> > wanted
> > > to change?
> > >
> > > Thank you!
> > > Benedikt
> > >
> > > Gary Gregory  schrieb am Di., 20. Sep. 2016 um
> > > 17:01 Uhr:
> > >
> > > > This annoying :-( it must be an EOL thing.
> > > >
> > > > Gary
> > > >
> > > > On Sep 20, 2016 7:18 AM, "Matt Sicker"  wrote:
> > > >
> > > > > Did the line ending change?
> > > > >
> > > > > On 20 September 2016 at 01:59, Benedikt Ritter  >
> > > > wrote:
> > > > >
> > > > > > Hello Gary,
> > > > > >
> > > > > > why has the whole file changed?
> > > > > >
> > > > > > Regards,
> > > > > > Benedikt
> > > > > >
> > > > > >  schrieb am Di., 20. Sep. 2016 um 07:40
> Uhr:
> > > > > >
> > > > > > > Repository: commons-io
> > > > > > > Updated Branches:
> > > > > > >   refs/heads/master 9ba9b49af -> 822bd135f
> > > > > > >
> > > > > > >
> > > > > > > Remove redundant type arguments.
> > > > > > >
> > > > > > > Project: http://git-wip-us.apache.org/
> repos/asf/commons-io/repo
> > > > > > > Commit:
> > http://git-wip-us.apache.org/repos/asf/commons-io/commit/
> > > > > > 822bd135
> > > > > > > Tree:
> > > > http://git-wip-us.apache.org/repos/asf/commons-io/tree/822bd135
> > > > > > > Diff:
> > > > http://git-wip-us.apache.org/repos/asf/commons-io/diff/822bd135
> > > > > > >
> > > > > > > Branch: refs/heads/master
> > > > > > > Commit: 822bd135f3a54b8fbeb23c313535b13c18198c3a
> > > > > > > Parents: 9ba9b49
> > > > > > > Author: Gary Gregory 
> > > > > > > Authored: Mon Sep 19 22:40:29 2016 -0700
> > > > > > > Committer: Gary Gregory 
> > > > > > > Committed: Mon Sep 19 22:40:29 2016 -0700
> > > > > > >
> > > > > > >
> > > > 
> --
> > > > > > >  .../commons/io/input/ObservableInputStream.java | 476
> > > > > > +--
> > > > > > >  1 file changed, 238 insertions(+), 238 deletions(-)
> > > > > > >
> > > > 
> --
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > http://git-wip-us.apache.org/repos/asf/commons-io/blob/
> > > > > > 822bd135/src/main/java/org/apache/commons/io/input/
> > > > > > ObservableInputStream.java
> > > > > > >
> > > > 
> --
> > > > > > > diff --git
> > > > > > >
> > > > a/src/main/java/org/apache/commons/io/input/
> ObservableInputStream.java
> > > > > > >
> > > > b/src/main/java/org/apache/commons/io/input/
> ObservableInputStream.java
> > > > > > > index 7d13472..c580ba4 100644
> > > > > > > --- a/src/main/java/org/apache/commons/io/input/
> > > > > > ObservableInputStream.java
> > > > > > > +++ b/src/main/java/org/apache/commons/io/input/
> > > > > > ObservableInputStream.java
> > > > > > > @@ -1,238 +1,238 @@
> > > > > > > -/*
> > > > > > > - * Licensed to the Apache Software Foundation (ASF) under one
> or
> > > > more
> > > > > > > - * contributor license agreements.  See the NOTICE file
> > > distributed
> > > > > with
> > > > > > > - * this work for additional information regarding copyright
> > > > ownership.
> > > > > > > - * The ASF licenses this file to You under the Apache License,
> > > > Version
> > > > > > 2.0
> > > > > > > - * (the "License"); you may not use this file except in
> > compliance
> > > > > with
> > > > > > > - * the License.  You may obtain a copy of the License at
> > > > > > > - *
> > > > > > > - *  http://www.apache.org/licenses/LICENSE-2.0
> > > > > > > - *
> > > > > > > - * Unless required by applicable law or agreed to in writing,
> > > > software
> > > > > > > - * distributed under the License is distributed on an "AS IS"
> > > BASIS,
> > > > > > > - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
> express
> > or
> > > > > > > implied.
> > > > > > > - * See the License for the specific language governing
> > permissions
> > > > and
> > > > > > > - * limitations under the License.
> > > > > > > - */
> > > > > > > 

[io] commons-io git repository ready

[Kristian Rosenvold]

Infra finally got round to fixing
https://issues.apache.org/jira/browse/INFRA-12077, and the repository
can now be seen at git://git.apache.org/commons-io.git


I have checked the repository and it looks ok. Anyone else want to
take a look that would be fine :) I will proceed with the documented
procedure tomorrow night.


Kristian

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

Re: [CSV] Git Migration

[Kristian Rosenvold]

Maybe if you switch the url from commons-cvs to commons-csv :)

https://git-wip-us.apache.org/repos/asf?p=commons-csv.git

K


2016-07-08 17:40 GMT+02:00 Gary Gregory :
> I notice that commons-compress is here:
>
> https://git-wip-us.apache.org/repos/asf/commons-compress.git
>
> But there is no
>
> https://git-wip-us.apache.org/repos/asf/commons-cvs.git
>
> ?
>
> Gary
>
>
> On Thu, Jul 7, 2016 at 11:33 PM, Benedikt Ritter  wrote:
>
>> Hi all,
>>
>> the migration has been processed. Infra has asked us to check the migration
>> [1]. The new Repository location is at [2].
>>
>> Next steps:
>> - check git repo
>> - replace the SVN repo with the moved txt file
>> - update website
>> - update jenkins job
>>
>> Benedikt
>>
>> [1]
>> https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-12092
>> [2] https://git1-us-west.apache.org/repos/asf?p=commons-csv.git
>>
>
>
>
> --
> 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: [lang] LANG-1247: FastDatePrinter generates Date objects wastefully closes #168

[Kristian Rosenvold]

2016-07-06 10:12 GMT+02:00 sebb :
> Have a look at the format method.
>
> It uses Calendar much as below.
>
>>> +final Calendar c = newCalendar();
>>> +c.setTimeInMillis(millis);
>>> +return applyRules(c, buf);


Yeah, I see now. Seems like I got lost in the overloads :)

Thanks,

Kristian

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

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

[Kristian Rosenvold]

+1 binding.

Kristian


2016-07-05 21:21 GMT+02:00 Oliver Heger :
> Because of the failing test I also feel a bit uneasy, but nevertheless I
> am +1: It is only a test class, the problem occurs only in a specific
> setup, it is already fixed in trunk, and the release is really overdue.
>
> Thanks
> Oliver
>
> Am 05.07.2016 um 11:16 schrieb Benedikt Ritter:
>> This vote is still pending and nobody has voted so far. Please review this
>> RC and cast your votes!
>>
>> Thank you!
>> Benedikt
>>
>> Benedikt Ritter  schrieb am Sa., 2. Juli 2016 um
>> 20:52 Uhr:
>>
>>> Hi,
>>>
>>> I'd like to release Apache Commons BCEL 6.0 based on RC7. Changes compared
>>> to RC6 are:
>>>
>>> - restored binary compatibility to a greater degree
>>> - fixed issue BCEL-262
>>>
>>> BCEL 6.0 RC7 is available for review here:
>>> https://dist.apache.org/repos/dist/dev/commons/bcel/ (svn revision 14251)
>>>
>>> The tag is here:
>>> http://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_RC7/
>>> (svn revision 1751084)
>>>
>>> Maven artifacts are here:
>>> https://repository.apache.org/content/repositories/orgapachecommons-1181/org/apache/bcel/bcel/6.0/
>>>
>>> These are the Maven artifacts and their hashes
>>>
>>> bcel-6.0-javadoc.jar
>>>   (SHA1: f1e1534867a901b9ba4884e5805317635c324589)
>>> bcel-6.0-sources.jar
>>>   (SHA1: 9ba3b50aa95289d01ec119b60be68eb4c608ba1d)
>>> bcel-6.0-test-sources.jar
>>>   (SHA1: 484b29d3a73fbe0c103d85965c4fd22e6253f545)
>>> bcel-6.0-tests.jar
>>>   (SHA1: f8b5857f3245e10548ef29cf7006c045b913a199)
>>> bcel-6.0.jar
>>>   (SHA1: fe1ecaf2ba3b1f9f18cdde4f13943e3ccc1d5e69)
>>> bcel-6.0.pom
>>>   (SHA1: ea17ee1b2c28804437212970ea2d273efeb3807e)
>>>
>>> I have tested this with JDK 7, 8 using Maven 3.3.9.
>>>
>>> Details of changes since 1.1 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-RC7/changes-report.html
>>>
>>> Site:
>>>   http://home.apache.org/~britter/commons/bcel/6.0-RC7/
>>> (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-RC7/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-RC7/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 21:00 CEST 05-July 2016
>>>
>>> [ ] +1 Release these artifacts
>>> [ ] +0 OK, but...
>>> [ ] -0 OK, but really should fix...
>>> [ ] -1 I oppose this release because...
>>>
>>> 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

Re: [lang] LANG-1247: FastDatePrinter generates Date objects wastefully closes #168

[Kristian Rosenvold]

2016-07-05 22:44 GMT+02:00  :
> LANG-1247: FastDatePrinter generates Date objects wastefully
> closes #168
>  public StringBuffer format(final long millis, final StringBuffer buf) {
> -return format(new Date(millis), buf);
> +final Calendar c = newCalendar();
> +c.setTimeInMillis(millis);
> +return applyRules(c, buf);


Arguably I might be a few years behind on developments regarding
java.lang.Calendar within the JDK, but from previous experience the
Calendar class is about as inefficient as things get, and anything
touching the calendar sprays your heap with objects. As far as I can
see, this just seems to be swapping around object allocation, probably
to the worse (instead of one visible object allocation within
commons-lang you're creating a fair bit of com.sun allocations as far
as I know)

I'd really like to see som evidence that this is an improvement, if
nothing else to enlighten me :)

Kristian

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

Re: Reformatting commons-io to single code style ?

[Kristian Rosenvold]

2016-06-27 12:18 GMT+02:00 sebb :
> This causes lots of grief when trying to track where a particular
> section of code was introduced.

Tooling has moved on, I'm really not sure this argument is
particularly relevant for a git repository.
If I want to track provenance I'd use git pickaxe or similar.

> Likewise so does reorganising methods alphabetically.

My OCD does not cover the order of the methods, this may be because I
think most of the applicable standards covering this are just plain
dumb.

> If the code in a particular source file is really badly mangled then
> it's worth standardising it internally, but IMO it's
> counter-productive to reformat everything.

I would not be writing this email if I thought it was just a minor few
hiccups. I think it's possible to define a code style for io that
causes a reasonable minimum changeset to the code.
As previously mentioned I really dont care about code style - as I've
grown older I even stopped rampaging against people that use tabs.


So the way I'm reading this I would probably get away by reformatting
the worst offenders, especially if I do not do too many files at once
(evil grin :)

Kristian

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

Reformatting commons-io to single code style ?

[Kristian Rosenvold]

This has probably been discussed a million times before, so I'll keep
it short. commons-io has wonderfully inconsistent code style even
within individual code files.

Once the move to git completes, I'd like to reformat the entire code
base (including javadoc) to a single style. I don't really care which
style, my OCD is about consistency, not about which particular style
is in use :)

(Is there any kind of intelliJ code style file for commons ?)

Sorry for disturbing the hornets :)

Kristian

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

Re: [VOTE] Move Apache Commons Primitives to dormant

[Kristian Rosenvold]

+1
12. jun. 2016 5.18 p.m. skrev "Benedikt Ritter" :

> Hi,
>
> there hasn't been any activity in the primitives component for a long
> while:
>
> - last release dates back to 2003-11-05
> - using svn log -l 50
> http://svn.apache.org/repos/asf/commons/proper/primitives/trunk I did not
> find a single commit that changed any of the code
> - no activity on dev@ and user@
>
> I think we can conclude that there is no more interest in this component.
> For this reason I'm calling a vote for moving the Apache Commons Primitives
> component to dormant. This vote will close no sooner that 72 hours from
> now, i.e. sometime after 17:30 CEST 12-June 2016.
>
> [ ] +1, yes move Primitives to dormant
> [ ] +/- 0, I'm not sure...
> [ ] -1, no, do NOT move Primitives to dormant, because...
>
> Thank you,
> Benedikt
>

Re: [VOTE][LAZY] Migrate Apache Commons IO to git

[Kristian Rosenvold]

This vote passes by lazy consensus.

The following people have voted +1:

- Jochen Wiedmann
- Sergio Fernández
- Gary Gregory
- James Carman

I'll take care of the migration and keep the ML updated about the progress.

Regards,
Kristian (Master of ^C^V)

2016-06-07 12:46 GMT+02:00 James Carman <ja...@carmanconsulting.com>:
> +1
>
> On Tue, Jun 7, 2016 at 2:37 AM Kristian Rosenvold <krosenv...@apache.org>
> wrote:
>
>> Hello,
>>
>> I'd like to call a VOTE by LAZY
>> consensus for migrating the Apache Commons IO component to git. Please
>> object to this vote if you see a problem with this. Otherwise this vote
>> will be considered as passed after 72 hours from now (10th June 2016, 09:00
>> CET)
>>
>> Thank you,
>> Kristian
>>

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

[VOTE][LAZY] Migrate Apache Commons IO to git

[Kristian Rosenvold]

Hello,

I'd like to call a VOTE by LAZY
consensus for migrating the Apache Commons IO component to git. Please
object to this vote if you see a problem with this. Otherwise this vote
will be considered as passed after 72 hours from now (10th June 2016, 09:00
CET)

Thank you,
Kristian

Re: [io] Make requirement Java 7?

[Kristian Rosenvold]

2016-04-26 15:39 GMT+02:00 Emmanuel Bourg :

> We are not alone :) RedHat is still maintaining OpenJDK 6 and providing
> security fixes for things like critical production systems not meant to
> be changed every two years.
>
>
Yes, and they are getting paid for it. If they need extended maintenance of
an old version they can do it themselves. We really do not need to be
backing anyones business model on our volunteer time.

I say just move the whole thing forward to jdk7 for the 2.6 release. This
is entirely undramatical. And I've been a proponent for relasing 2.5 on 1.6
:)


Kristian

Re: [ANN] Apache Commons IO 2.5 Released

[Kristian Rosenvold]

22. apr. 2016 15.38 skrev "sebb" :

> On 22 April 2016 at 12:29, Benson Margulies  wrote:
> > I thought I saw it. I guess I was wrong. I wonder what's taking so long?
>
> Even when Central is working well, it can take several hours (up to a
> day) to synch.
>
> That is partly why the instructions say to wait.
>
>
As can be seen from the issue, we should be on a 10 minute synch. There's
always room for the occasional hiccups, but it should be easy for the RM to
just check central.

Kristian

Re: [ANN] Apache Commons IO 2.5 Released

[Kristian Rosenvold]

Looks like something is amiss with the central sync, the artifacts are at
https://repository.apache.org/content/groups/public/commons-io/commons-io/

You probably need to file an issue with mvncentral.

While you're at that, you can request in the same issue that all of the
"commons" artifacts be set at the new and improved central-synch schedule,
which reduces the classic 4 hour delay to just a few minutes.

Kristian




2016-04-22 13:29 GMT+02:00 Benson Margulies :

> I thought I saw it. I guess I was wrong. I wonder what's taking so long?
>
> On Fri, Apr 22, 2016 at 1:46 AM, Gary Gregory 
> wrote:
> > It's not on Central yet for example:
> >
> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22commons-io%22%20AND%20a%3A%22commons-io%22
> >
> > G
> >
> > On Thu, Apr 21, 2016 at 6:38 PM, Benson Margulies  >
> > wrote:
> >
> >> On Thu, Apr 21, 2016 at 9:34 PM, sebb  wrote:
> >> > The announce message should not be sent until a day or so after the
> >> > artifacts have been published in order to give time for the mirrors to
> >> > catch up.
> >> >
> >> > At that point the site can be updated, the announce sent, and older
> >> > versions removed.
> >> >
> >> > Otherwise some users will get 404s
> >>
> >>
> >> Sebb, I'm honestly not sure it matters. I've RMed many, many, releases
> >> of Maven components, I've always sent the announcement out as soon as
> >> I could verify the content on the web site and Maven central, and I've
> >> never seen a complaint about a 404.
> >>
> >> My suspicion is that nearly no one bothers to download from the
> >> mirrors, compared to the people who just update their poms or
> >> ivy.xml's or whatever.
> >>
> >> Maybe the users of commons are different.
> >>
> >> Anyway, if you can help me find out why the new javadoc refuses to
> >> show up, I'd be grateful.
> >>
> >> --benson
> >>
> >>
> >> >
> >> > This should be explained in the release docs.
> >> >
> >> >
> >> > On 22 April 2016 at 02:08, Benson Margulies 
> >> wrote:
> >> >> Commons IO is a Java library of utilities to assist with developing
> IO
> >> >> functionality.
> >> >>
> >> >> Release notes for version 2.5 are at
> >> >> https://commons.apache.org/proper/commons-io/upgradeto2_5.html.
> >> >>
> >> >> -
> >> >> 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
> >>
> >>
> >
> >
> > --
> > 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: [io] 2.5 vote...

[Kristian Rosenvold]

RC2 was cancelled. I was planning to pick up RC3 RSN, maybe this weekend.

Kristian


2016-01-14 23:21 GMT+01:00 Gary Gregory :

> Kristian, others? What happened to releasing 2.5 or tallying the RC vote?
>
> Thank you,Gary
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>

Re: [VOTE] Release commons-io RC2

[Kristian Rosenvold]

Thanks a lot for a thorough review ! This vote is cancelled for an
immedieate respin.

Kristian


2015-12-26 18:34 GMT+01:00 Phil Steitz <phil.ste...@gmail.com>:

> Sigs and hashes are good.
>
> Release contents are good.
>
> Ant and maven builds both tested on 1.7, 1.8.
>
> Coburta disease has been cured - tests run cleanly against the
> release jar.
>
> Unfortunately, the NOTICE file still has not had the copyright date
> updated.
>
> I think that is a blocker, so -1 from me.
>
> Not blocking:
>
> There are a couple of Checkstyle and Findbugs errors that should be
> fixed or suppressed.  I am not sure whether or not the Findbugs
> errors indicate actual problems.  If they do, these should be fixed;
> otherwise suppression should be configured.
>
> Phil
>
>
>
> On 12/23/15 2:14 PM, Kristian Rosenvold wrote:
> > We have fixed quite a few bugs and added some significant
> > enhancements since commons-io was released,
> > so I would like to release commons-io 2.5
> >
> > commons-io 2.5 RC2 is available for review here:
> >   https://dist.apache.org/repos/dist/dev/commons/io/ (svn revision
>  11732)
> >
> >  Maven artifacts are here:
> >
> > https://repository.apache.org/content/repositories/orgapachecommons-1136
> >
> >
> >  Details of changes since 2.4 are in the release notes:
> > https://dist.apache.org/repos/dist/dev/commons/io/RELEASE-NOTES.txt
> > http://people.apache.org/~krosenvold/commons-io
> > -2.5-RC2/changes-report.html
> > <
> http://people.apache.org/~krosenvold/commons-io-2.5-RC1/changes-report.html
> >
> >
> >  I have tested this with JDK 1.6, 1.7 and 1.8, IBM JDK 1.6, IBM JDK 1.7
> >
> > Users testing on Windows may want to take note of
> > https://issues.apache.org/jira/browse/IO-490, which
> > is an old issue causing intermittent failures on Windows that is
> unchanged
> > as of this release.
> >
> >
> > The tag is here https://svn.apache.org/repos/asf/commons/proper/io/tags/
> > commons-io-2.5-RC
> > <
> https://svn.apache.org/repos/asf/commons/proper/io/tags/commons-io-2.5-RC1
> >
> > 2
> > (r1721575)
> >
> > Site:
> >  http://people.apache.org/~krosenvold/commons-io-2.5-RC2/
> > <http://people.apache.org/~krosenvold/commons-io-2.5-RC1/>
> >(note some *relative* links are broken and the 2.5 directories are
> >not yet created - these will be OK once the site is deployed)
> >
> >
> >Clirr Report (compared to 2.4):
> >   http://people.apache.org/~krosenvold/commons-io
> > -2.5-RC2/clirr-report.html
> > <
> http://people.apache.org/~krosenvold/commons-io-2.5-RC1/clirr-report.html>
> >
> >
> >RAT Report:
> >   http://people.apache.org/~krosenvold/commons-io
> > -2.5-RC2/rat-report.html
> > <http://people.apache.org/~krosenvold/commons-io-2.5-RC1/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
> >  23:00 CET 26-Dec 2015
> >
> >  [ ] +1 Release these artifacts
> >  [ ] +0 OK, but...
> >  [ ] -0 OK, but really should fix...
> >  [ ] -1 I oppose this release because...
> >
> >
> > Kristian
> >
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VOTE] Release commons-io RC2

[Kristian Rosenvold]

Using all my klutzy 10 thumbs I re-added the checksums in r11735, which
should fix the problem and allow the vote to proceed.


Kristian

2015-12-24 4:19 GMT+01:00 Gary Gregory <garydgreg...@gmail.com>:

> -1
>
> MD5 and SHA1 sums do not match:
>
> $ md5sum commons-io-2.5-src.zip
> 75f886de5526b3cc517eaa7b383e57d6 *commons-io-2.5-src.zip
>
> $ cat commons-io-2.5-src.zip.md5
> e5844f9b3eaab2f2625da21b9f2e994e
>
> $ sha1sum commons-io-2.5-src.zip
> 585b0cfe1a6194d40ef70c0ec0b6925bca1856d7 *commons-io-2.5-src.zip
>
> $ cat commons-io-2.5-src.zip.sha1
> 99b9fac8122d6249e0f958ebaf9e2ab4612845d8
>
> Gary
>
> On Wed, Dec 23, 2015 at 1:14 PM, Kristian Rosenvold <krosenv...@apache.org
> >
> wrote:
>
> > We have fixed quite a few bugs and added some significant
> > enhancements since commons-io was released,
> > so I would like to release commons-io 2.5
> >
> > commons-io 2.5 RC2 is available for review here:
> >   https://dist.apache.org/repos/dist/dev/commons/io/ (svn revision
> >  11732)
> >
> >  Maven artifacts are here:
> >
> > https://repository.apache.org/content/repositories/orgapachecommons-1136
> >
> >
> >  Details of changes since 2.4 are in the release notes:
> > https://dist.apache.org/repos/dist/dev/commons/io/RELEASE-NOTES.txt
> > http://people.apache.org/~krosenvold/commons-io
> > -2.5-RC2/changes-report.html
> > <
> >
> http://people.apache.org/~krosenvold/commons-io-2.5-RC1/changes-report.html
> > >
> >
> >  I have tested this with JDK 1.6, 1.7 and 1.8, IBM JDK 1.6, IBM JDK 1.7
> >
> > Users testing on Windows may want to take note of
> > https://issues.apache.org/jira/browse/IO-490, which
> > is an old issue causing intermittent failures on Windows that is
> unchanged
> > as of this release.
> >
> >
> > The tag is here https://svn.apache.org/repos/asf/commons/proper/io/tags/
> > commons-io-2.5-RC
> > <
> >
> https://svn.apache.org/repos/asf/commons/proper/io/tags/commons-io-2.5-RC1
> > >
> > 2
> > (r1721575)
> >
> > Site:
> >  http://people.apache.org/~krosenvold/commons-io-2.5-RC2/
> > <http://people.apache.org/~krosenvold/commons-io-2.5-RC1/>
> >(note some *relative* links are broken and the 2.5 directories are
> >not yet created - these will be OK once the site is deployed)
> >
> >
> >Clirr Report (compared to 2.4):
> >   http://people.apache.org/~krosenvold/commons-io
> > -2.5-RC2/clirr-report.html
> > <
> http://people.apache.org/~krosenvold/commons-io-2.5-RC1/clirr-report.html
> > >
> >
> >
> >RAT Report:
> >   http://people.apache.org/~krosenvold/commons-io
> > -2.5-RC2/rat-report.html
> > <http://people.apache.org/~krosenvold/commons-io-2.5-RC1/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
> >  23:00 CET 26-Dec 2015
> >
> >  [ ] +1 Release these artifacts
> >  [ ] +0 OK, but...
> >  [ ] -0 OK, but really should fix...
> >  [ ] -1 I oppose this release because...
> >
> >
> > Kristian
> >
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>

[VOTE] Release commons-io RC2

[Kristian Rosenvold]

We have fixed quite a few bugs and added some significant
enhancements since commons-io was released,
so I would like to release commons-io 2.5

commons-io 2.5 RC2 is available for review here:
  https://dist.apache.org/repos/dist/dev/commons/io/ (svn revision   11732)

 Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1136


 Details of changes since 2.4 are in the release notes:
https://dist.apache.org/repos/dist/dev/commons/io/RELEASE-NOTES.txt
http://people.apache.org/~krosenvold/commons-io
-2.5-RC2/changes-report.html


 I have tested this with JDK 1.6, 1.7 and 1.8, IBM JDK 1.6, IBM JDK 1.7

Users testing on Windows may want to take note of
https://issues.apache.org/jira/browse/IO-490, which
is an old issue causing intermittent failures on Windows that is unchanged
as of this release.


The tag is here https://svn.apache.org/repos/asf/commons/proper/io/tags/
commons-io-2.5-RC

2
(r1721575)

Site:
 http://people.apache.org/~krosenvold/commons-io-2.5-RC2/

   (note some *relative* links are broken and the 2.5 directories are
   not yet created - these will be OK once the site is deployed)


   Clirr Report (compared to 2.4):
  http://people.apache.org/~krosenvold/commons-io
-2.5-RC2/clirr-report.html



   RAT Report:
  http://people.apache.org/~krosenvold/commons-io
-2.5-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
 23:00 CET 26-Dec 2015

 [ ] +1 Release these artifacts
 [ ] +0 OK, but...
 [ ] -0 OK, but really should fix...
 [ ] -1 I oppose this release because...


Kristian

Re: [io] Java 7

[Kristian Rosenvold]

I'd still like to make 2.5 a 1.6 release, it shouldnt be that far off. Can
you put it on a branch for now ?
16. des. 2015 18.46 skrev "Gary Gregory" :

> Hi All:
>
> I was about to add some APIs to FileUtils that work with Java 7 Paths but
> [io] is still on Java 6.
>
> Are we OK to move to Java 7?
>
> But maybe we should have a PathUtils instead?
>
> Gary
>
> --
> 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
>

[io] IBM JDK and broken UTF-16 (Related to release 2.5 RC 1)

[Kristian Rosenvold]

I've been digging deeply into the IBM JDK 6/7 related breakages on IO RC
2.5.

A lot of them can be explained by different capabilities of XML parsers in
the different JDKs, and I have come up with a decent heuristic for
detecting this and ignoring the tests.

There are also a couple of legacy oddball character sets supported by the
IBM JDK that simply do not support round-tripping the french string in the
testcase. (Nerdy side note; Take a look at the 7-bit japanese/chinese
https://en.wikipedia.org/wiki/ISO/IEC_2022 !). These can just be excluded
from the testcase.

But the UTF-16 decoder in IBM JDK 6 and 7 is simply broken when fed
single-bytes at a time (it works fine with a full byte array input). This
is bad news for the WriterOutputStream, which is quite fundamentally based
on outputting single bytes. Where the other problems can be fixed by
improving the testcase, I really believe the  WriterOutputStream should
just throw UnsupportedOperationException on IBM JDK6/7 with UTF16.

WDYT ?

Kristian

Re: [VOTE] Release commons-io 2.5 based on RC1

[Kristian Rosenvold]

The Charset related tests fail due some character set that is installed in
your environment that is nor present in mine (commons.io builds fine on IBM
jdk6 & 7 here). To try to identify which character set we're talking about
I added the name to the assert message; there is already logic in place in
these tests to ignore specific character sets.

If you can run the latest commons-io trunk on your system right now, you
should get the name of the failing character set and hopefully I can
install it here and analyze the problem a little more or ignore that
specific character set.

The TailerTest was doing two different things which are both problematic;
it was relying on Thread.sleep(X) sleeping anything remotelly similar to X
ms, which is known to be untrue. Additionally there is a reliance on gc
actually running in this interval, which is even more questionable.

I have "fixed" the sleep part of this issue, leaving the reliance on
deterministic gc invocation (which I still believe cannot really be done
reliably without resorting to the debugger api). If this test fails on any
of your environments I'm partial to just deleting the tests as "not
possible".

Let me know about the charset and any other problems you might encounter
and I'll try to fix them  before spinning RC2 (hopefully this weekend).

Kristian


2015-11-26 14:20 GMT+01:00 Jörg Schaible <joerg.schai...@gmx.de>:

> Kristian Rosenvold wrote:
>
> >   We have fixed quite a few bugs and added some significant
> > enhancements since commons-io was released,
> >   so I would like to release commons-io 2.5
> >
> >   Foo 2.5 RC1 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/io/ (svn revision
> > 11266)
> >
> >   Maven artifacts are here:
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1123
> >
> >   Details of changes since 2.4 are in the release notes:
> > https://dist.apache.org/repos/dist/dev/commons/io/RELEASE-NOTES.txt
> >
> http://people.apache.org/~krosenvold/commons-io-2.5-RC1/changes-report.html
> >
> >   I have tested this with JDK 1.6, 1.7 and 1.8.
> >
> >   The tag is here:
> >
> https://svn.apache.org/repos/asf/commons/proper/io/tags/commons-io-2.5-RC1
> > (r1715890)
> >
> >   Site:
> >  http://people.apache.org/~krosenvold/commons-io-2.5-RC1/
> >   (note some *relative* links are broken and the 2.5 directories are
> >   not yet created - these will be OK once the site is deployed)
> >
> >   Clirr Report (compared to 2.4):
> >
> http://people.apache.org/~krosenvold/commons-io-2.5-RC1/clirr-report.html
> >
> >
> >   RAT Report:
> >
> http://people.apache.org/~krosenvold/commons-io-2.5-RC1/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
> > 19:00 CET 26-March 2015
> >
> >   [ ] +1 Release these artifacts
> >   [ ] +0 OK, but...
> >   [ ] -0 OK, but really should fix...
> >   [ ] -1 I oppose this release because...
>
>
> IBM JDK 1.6 fails (as usual):
> === %< ===
> Failed tests:
>   CharSequenceInputStreamTest.testBufferedRead_AvailableCharset:96-
> >testBufferedRead:72 bytes should agree expected:<65> but was:<71>
>   WriterOutputStreamTest.testUTF16WithSingleByteWrite:81-
> >testWithSingleByteWrite:47 expected:<[à peine arrivés nous entrâmes dans
> sa
> chambre]> but was:<[＀ 瀀攀椀渀攀 愀爀爀椀瘀猀 渀漀甀猀 攀渀琀爀洀攀猀 搀愀渀猀 猀愀 挀栀愀洀戀爀]>
> Tests in error:
>   BOMInputStreamTest.testReadXmlWithBOMUcs2:602->parseXml:158 » SAXParse
> Content...
>   BOMInputStreamTest.testReadXmlWithBOMUcs4:615->parseXml:158 » SAXParse
> Content...
>   BOMInputStreamTest.testReadXmlWithBOMUtf32Be:638->parseXml:158 » SAXParse
> Inva...
>   BOMInputStreamTest.testReadXmlWithBOMUtf32Le:647->parseXml:158 » SAXParse
> Inva...
>   BOMInputStreamTest.testReadXmlWithoutBOMUtf32Be:664->parseXml:158 »
> SAXParse I...
>   BOMInputStreamTest.testReadXmlWithoutBOMUtf32Le:672->parseXml:158 »
> SAXParse I...
>   CharSequenceInputStreamTest.testAvailable:430->testAvailableSkip:391 »
> UnsupportedOperation
>
> Tests run: 1156, Failures: 2, Errors: 7, Skipped: 2
> === %< ===
>
> IBM JDK 1.7 fails also:
> === %< ===
> Failed tests:
>   CharSequenceInputStreamTest.testBufferedRead_AvailableCharset:96-
> >testBufferedRead:72 bytes should agree expected:<111

[VOTE] Release commons-io 2.5 based on RC1 - Cancelled

[Kristian Rosenvold]

mmons.io.FileUtilsTestCase)  Time elapsed: 0
>> sec  <<< ERROR!
>> java.io.IOException: Cannot create file
>>
>> C:\data\dev\projects\OpenSource\io\commons-io-2.5-src\test\io\file1-test.txt
>> as the parent directory does not exist
>> at
>>
>> org.apache.commons.io.testtools.FileBasedTestCase.createFile(FileBasedTestCase.java:60)
>> at
>> org.apache.commons.io.FileUtilsTestCase.setUp(FileUtilsTestCase.java:101)
>>
>> With Java 1.8 it is worse; here I get 71 errors which are mostly similar
>> to the one before (all in FileUtilsTestCase).
>>
>> The site looks okay except for the JIRA report which is missing.
>>
>> -1
>>
>> Sorry
>> Oliver
>>
>>
>> Am 23.11.2015 um 18:31 schrieb Kristian Rosenvold:
>> >   We have fixed quite a few bugs and added some significant
>> > enhancements since commons-io was released,
>> >   so I would like to release commons-io 2.5
>> >
>> >   Foo 2.5 RC1 is available for review here:
>> > https://dist.apache.org/repos/dist/dev/commons/io/ (svn revision
>> 11266)
>> >
>> >   Maven artifacts are here:
>> >
>> https://repository.apache.org/content/repositories/orgapachecommons-1123
>> >
>> >   Details of changes since 2.4 are in the release notes:
>> > https://dist.apache.org/repos/dist/dev/commons/io/RELEASE-NOTES.txt
>> >
>> http://people.apache.org/~krosenvold/commons-io-2.5-RC1/changes-report.html
>> >
>> >   I have tested this with JDK 1.6, 1.7 and 1.8.
>> >
>> >   The tag is here:
>> >
>> https://svn.apache.org/repos/asf/commons/proper/io/tags/commons-io-2.5-RC1
>> > (r1715890)
>> >
>> >   Site:
>> >  http://people.apache.org/~krosenvold/commons-io-2.5-RC1/
>> >   (note some *relative* links are broken and the 2.5 directories are
>> >   not yet created - these will be OK once the site is deployed)
>> >
>> >   Clirr Report (compared to 2.4):
>> >
>> http://people.apache.org/~krosenvold/commons-io-2.5-RC1/clirr-report.html
>> >
>> >
>> >   RAT Report:
>> >
>> http://people.apache.org/~krosenvold/commons-io-2.5-RC1/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
>> > 19:00 CET 26-March 2015
>> >
>> >   [ ] +1 Release these artifacts
>> >   [ ] +0 OK, but...
>> >   [ ] -0 OK, but really should fix...
>> >   [ ] -1 I oppose this release because...
>> >
>> >   Thanks!
>> >
>> >
>> > Kristian
>> >
>> > -
>> > 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
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> 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

[VOTE] Release commons-io 2.5 based on RC1

[Kristian Rosenvold]

  We have fixed quite a few bugs and added some significant
enhancements since commons-io was released,
  so I would like to release commons-io 2.5

  Foo 2.5 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/io/ (svn revision 11266)

  Maven artifacts are here:
   https://repository.apache.org/content/repositories/orgapachecommons-1123

  Details of changes since 2.4 are in the release notes:
https://dist.apache.org/repos/dist/dev/commons/io/RELEASE-NOTES.txt
http://people.apache.org/~krosenvold/commons-io-2.5-RC1/changes-report.html

  I have tested this with JDK 1.6, 1.7 and 1.8.

  The tag is here:
https://svn.apache.org/repos/asf/commons/proper/io/tags/commons-io-2.5-RC1
(r1715890)

  Site:
 http://people.apache.org/~krosenvold/commons-io-2.5-RC1/
  (note some *relative* links are broken and the 2.5 directories are
  not yet created - these will be OK once the site is deployed)

  Clirr Report (compared to 2.4):
 http://people.apache.org/~krosenvold/commons-io-2.5-RC1/clirr-report.html


  RAT Report:
 http://people.apache.org/~krosenvold/commons-io-2.5-RC1/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
19:00 CET 26-March 2015

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

  Thanks!


Kristian

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

commons-io 2.5 RC1 tomorrow

[Kristian Rosenvold]

I've been through the latest changes on the
ValidatingObjectInputStream and I think they look good.

RC1 vote starts in approx 20 hrs, if anyone else wants to take a final look.

Kristian

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

Re: SafeObjectInputStream in Commons?

[Kristian Rosenvold]

I'd think commons-io too. I have once again startes moves to release the
next version so if you're quick I can review & incorporate it. Remember
testcases :)

Kristian
13. nov. 2015 18.00 skrev "Bertrand Delacretaz" :

> Hi,
>
> I've just subscribed to this list after briefly discussing this with
> Benedikt Ritter.
>
> I have written a small module [1] that provides a safer replacement
> for ObjectInputStream, to avoid the recently discussed Java
> deserialization issues.
>
> For now that module is in my Sling whiteboard but I'd be interested in
> donating it to Commons if you guys think it's a good idea, and
> maintaining it here if you agree.
>
> This SafeObjectInputStream uses a ClassAcceptor [2] interface to only
> allow restricted sets of classes to be deserialized. An efficient
> whitelist-based ClassAcceptor is provided, as well as a more flexible
> and slower RegexpClassAcceptor that has both white and black lists -
> and of course one can supply their own ClassAcceptor implementation.
>
> Are you guys interested? From my point of view it's good enough to
> release, it just needs additional OSGi Export-Package headers to be
> usable in an OSGi environment like Sling.
>
> Let me know what you think.
>
> -Bertrand
>
> [1]
> https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/safe-object-input-stream/
>
> [2]
> https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/safe-object-input-stream/src/main/java/org/apache/sling/deserialization/ClassAcceptor.java
> - it's basically just a "void accept(String className) throws
> ClassRejectedException" method.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [io] When will version 2.5 be released?

[Kristian Rosenvold]

It should happen about -90 days but go hung up in summer vacation,
which is extensive over here. The release is basically ready (minus
one small issue with an added method to an interface), but I'll see if
I can bring this back on track "real soon". Watch this space :)

Kristian


2015-10-22 20:54 GMT+02:00 Pascal Schumacher :
> Hi everybody,
>
> as far as I remember a few weeks ago there were plans to release commons-io
> 2.5?
>
> Any news on when it will be released?
>
> I'm eagerly waiting for some of the new additions. :)
>
> -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: [validator] Inconsistent behavior in UrlValidator

[Kristian Rosenvold]

127.0.0.1 is not always the address for localhost. This is a can of worms
big enough to drive a medium-sized container ship into

Kristian
27. sep. 2015 4.13 p.m. skrev "Benedikt Ritter" :

> Hm... since localhost is usually only an alias for 127.0.0.1 it doesn't
> really make sense to allow one but not the other.
>
> 2015-09-25 23:18 GMT+02:00 Adrian Crum  >:
>
> > I was just looking at the UrlValidator test and I noticed that localhost
> > is allowed in the URL if the ALLOW_LOCAL_URLS flag is set, and it is not
> > allowed if the ALLOW_LOCAL_URLS flag is not set.
> >
> > If the ALLOW_LOCAL_URLS is not set, a loopback IP address (127.0.0.1) URL
> > will validate. It seems to me that it shouldn't - to be consistent with
> the
> > localhost behavior.
> >
> > What do you think?
> >
> > --
> > Adrian Crum
> > Sandglass Software
> > www.sandglass-software.com
> >
> > -
> > 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
>

Re: [validator] Inconsistent behavior in UrlValidator

[Kristian Rosenvold]

Yeah, as long as the full range is validated it should be fine.

K


2015-09-27 19:17 GMT+02:00 Adrian Crum <adrian.c...@sandglass-software.com>:
> The address range 127.0.0.0 to 127.255.255.255 is reserved for loopback
> testing. It seems pretty straightforward to me.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 9/27/2015 8:07 AM, Kristian Rosenvold wrote:
>>
>> 127.0.0.1 is not always the address for localhost. This is a can of worms
>> big enough to drive a medium-sized container ship into
>>
>> Kristian
>> 27. sep. 2015 4.13 p.m. skrev "Benedikt Ritter" <brit...@apache.org>:
>>
>>> Hm... since localhost is usually only an alias for 127.0.0.1 it doesn't
>>> really make sense to allow one but not the other.
>>>
>>> 2015-09-25 23:18 GMT+02:00 Adrian Crum
>>> <adrian.c...@sandglass-software.com
>>>>
>>>> :
>>>
>>>
>>>> I was just looking at the UrlValidator test and I noticed that localhost
>>>> is allowed in the URL if the ALLOW_LOCAL_URLS flag is set, and it is not
>>>> allowed if the ALLOW_LOCAL_URLS flag is not set.
>>>>
>>>> If the ALLOW_LOCAL_URLS is not set, a loopback IP address (127.0.0.1)
>>>> URL
>>>> will validate. It seems to me that it shouldn't - to be consistent with
>>>
>>> the
>>>>
>>>> localhost behavior.
>>>>
>>>> What do you think?
>>>>
>>>> --
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>>
>>>> -
>>>> 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
>

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

Version number for next commons-io

[Kristian Rosenvold]

The next release is binary compatible except for *1* method that has
been added to a (fairly infrequently used) interface. Does that still
mean I should burn 2.5 and go for 3.0. And would that be 3.0 or 3.0.0
?

Kristian

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

Re: Version number for next commons-io

[Kristian Rosenvold]

Just to be clear on this, the breach is adding an interface to

org.apache.commons.io.input.TailerListener#endOfFileReached
and will probably only affect a few users. I'm documenting this in
release notes.

Personally I'd say this is 2.5 simply due to its very limited impact,
but version numbers are cheap :)

Kristian



2015-09-19 12:32 GMT+02:00 Kristian Rosenvold <krosenv...@apache.org>:
> The next release is binary compatible except for *1* method that has
> been added to a (fairly infrequently used) interface. Does that still
> mean I should burn 2.5 and go for 3.0. And would that be 3.0 or 3.0.0
> ?
>
> Kristian

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

Re: Version number for next commons-io

[Kristian Rosenvold]

2015-09-19 13:58 GMT+02:00 Kristian Rosenvold <krosenv...@apache.org>:
> Just to be clear on this, the breach is adding an interface to
Oops. The breach is adding a /method/.

>
> org.apache.commons.io.input.TailerListener#endOfFileReached
> and will probably only affect a few users. I'm documenting this in
> release notes.

Kristian

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

Missing nexus "stage" permissions....

[Kristian Rosenvold]

Nexus seems to think I am missing permissions to stage;


2015-09-10 07:39:36 ERROR [9864571-1641733] -
com.sonatype.nexus.staging.rest.deploy.DeployResource - Got exception
during processing request "PUT
http://repository.apache.org/service/local/staging/deploy/maven2/commons-io/commons-io/2.5/commons-io-2.5.pom":
User 'krosenvold' missing 'stage' permission for staging profile:
165891100a26f



Can someone fix this ?

Kristian

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

Re: Missing nexus "stage" permissions....

[Kristian Rosenvold]

As you can see, that did the trick ! Thanks a lot.

Kristian


2015-09-10 10:18 GMT+02:00 sebb <seb...@gmail.com>:
> On 10 September 2015 at 08:42, Kristian Rosenvold <krosenv...@apache.org> 
> wrote:
>> Nexus seems to think I am missing permissions to stage;
>>
>>
>> 2015-09-10 07:39:36 ERROR [9864571-1641733] -
>> com.sonatype.nexus.staging.rest.deploy.DeployResource - Got exception
>> during processing request "PUT
>> http://repository.apache.org/service/local/staging/deploy/maven2/commons-io/commons-io/2.5/commons-io-2.5.pom":
>> User 'krosenvold' missing 'stage' permission for staging profile:
>> 165891100a26f
>
> I wonder if that is because you are not in the Commons LDAP unix group?
> (However you are in the LDAP committee - PMC - group)
>
> I have now added you to the unix group. If this does not fix the
> issue, you will have to raise a JIRA INFRA (Nexus) issue.
>
> (Note it will take a while for the people.a.o website to show the
> change, but I assume Nexus will take note immediately)
>
>>
>>
>> Can someone fix this ?
>>
>> Kristian
>>
>> -
>> 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: [VOTE] Move COMPRESS to git

[Kristian Rosenvold]

+1
22. aug. 2015 21.29 skrev Stefan Bodewig bode...@apache.org:

 Hi all

 more thann half a year ago I promised to call for a vote for migrating
 to git as soon as 1.10 has been released.  Well that took longer than
 expected :-)

 Anyway, here is the vote:

 +1 Move to git
 -1 Stick with svn

 vote will be open for 72 hours

 Cheers

 Stefan

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

Re: [VOTE] Release Commons Compress Based on RC3

[Kristian Rosenvold]

I found the source of the regression, outside c-c.

So here's my +1 for the release.

Kristian


2015-08-18 12:12 GMT+02:00 Kristian Rosenvold krosenv...@apache.org:
 I'm investigating a regression in the maven test suites with this
 version of c-c (related to zip file attributes). At the moment I do
 not know if c-c is the culprit. Please give me an extra day before
 closing this vote.

 Kristian


 2015-08-16 20:02 GMT+02:00 Oliver Heger oliver.he...@oliver-heger.de:
 Building with Java 1.5 caused an OutOfMemoryError, but was successful
 with 1.6 and 1.8. ISTR that I had similar problems with the previous
 release, so not blocking. Artifacts and site look good.

 +1

 Oliver

 My environment:
 Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
 2014-02-14T18:37:52+01:00)
 Maven home: C:\data\dev\tools\apache-maven-3.2.1\bin\..
 Java version: 1.8.0_45, vendor: Oracle Corporation
 Java home: C:\Program Files\Java\jdk1.8.0_45\jre
 Default locale: de_DE, platform encoding: Cp1252
 OS name: windows 8.1, version: 6.3, arch: amd64, family: dos
 (actually, it is Windows 10)

 Am 15.08.2015 um 18:57 schrieb Stefan Bodewig:
 Hi all

 third attempt after six months, last time we couldn't agree on how we
 wanted to treat the protected members of LZWInputStream, but this seems
 to be resolved with COMPRESS-300 now.  So this is a fresh attempt.

 JIRA says we've fixed 19 issues and the changes to the zip packages are
 long overdue.

 Compress 1.10 RC3 is available for review here:
 https://dist.apache.org/repos/dist/dev/commons/compress/
 (svn revision 10183)

 Maven artifacts are here:
 
 https://repository.apache.org/content/repositories/orgapachecommons-1106/org/apache/commons/commons-compress/1.10/

 Details of changes since 1.1 are in the release notes:
 
 https://dist.apache.org/repos/dist/dev/commons/compress/RELEASE-NOTES.txt
 http://people.apache.org/~bodewig/compress-1.10-RC3/changes-report.html

 I have tested this with JDK 1.7 and 1.8 using maven3.

 The tag is here:
 
 https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.10-RC3
 (svn revision 1696055)

 Site:
 http://people.apache.org/~bodewig/compress-1.10-RC3/

 As I've always done in the past I intend to re-create and publish the
 site once the release date is set.  The Javadocs 1.10 link is dead until
 then.

 Clirr Report (compared to 1.9):
 http://people.apache.org/~bodewig/compress-1.10-RC3/clirr-report.html

 RAT Report:
 http://people.apache.org/~bodewig/compress-1.10-RC3/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 1700
 GMT 18-August 2015

   [ ] +1 Release these artifacts
   [ ] +0 OK, but...
   [ ] -0 OK, but really should fix...
   [ ] -1 I oppose this release because...


 -
 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: [VOTE] Release Commons Compress Based on RC3

[Kristian Rosenvold]

I'm investigating a regression in the maven test suites with this
version of c-c (related to zip file attributes). At the moment I do
not know if c-c is the culprit. Please give me an extra day before
closing this vote.

Kristian


2015-08-16 20:02 GMT+02:00 Oliver Heger oliver.he...@oliver-heger.de:
 Building with Java 1.5 caused an OutOfMemoryError, but was successful
 with 1.6 and 1.8. ISTR that I had similar problems with the previous
 release, so not blocking. Artifacts and site look good.

 +1

 Oliver

 My environment:
 Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
 2014-02-14T18:37:52+01:00)
 Maven home: C:\data\dev\tools\apache-maven-3.2.1\bin\..
 Java version: 1.8.0_45, vendor: Oracle Corporation
 Java home: C:\Program Files\Java\jdk1.8.0_45\jre
 Default locale: de_DE, platform encoding: Cp1252
 OS name: windows 8.1, version: 6.3, arch: amd64, family: dos
 (actually, it is Windows 10)

 Am 15.08.2015 um 18:57 schrieb Stefan Bodewig:
 Hi all

 third attempt after six months, last time we couldn't agree on how we
 wanted to treat the protected members of LZWInputStream, but this seems
 to be resolved with COMPRESS-300 now.  So this is a fresh attempt.

 JIRA says we've fixed 19 issues and the changes to the zip packages are
 long overdue.

 Compress 1.10 RC3 is available for review here:
 https://dist.apache.org/repos/dist/dev/commons/compress/
 (svn revision 10183)

 Maven artifacts are here:
 
 https://repository.apache.org/content/repositories/orgapachecommons-1106/org/apache/commons/commons-compress/1.10/

 Details of changes since 1.1 are in the release notes:
 https://dist.apache.org/repos/dist/dev/commons/compress/RELEASE-NOTES.txt
 http://people.apache.org/~bodewig/compress-1.10-RC3/changes-report.html

 I have tested this with JDK 1.7 and 1.8 using maven3.

 The tag is here:
 
 https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.10-RC3
 (svn revision 1696055)

 Site:
 http://people.apache.org/~bodewig/compress-1.10-RC3/

 As I've always done in the past I intend to re-create and publish the
 site once the release date is set.  The Javadocs 1.10 link is dead until
 then.

 Clirr Report (compared to 1.9):
 http://people.apache.org/~bodewig/compress-1.10-RC3/clirr-report.html

 RAT Report:
 http://people.apache.org/~bodewig/compress-1.10-RC3/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 1700
 GMT 18-August 2015

   [ ] +1 Release these artifacts
   [ ] +0 OK, but...
   [ ] -0 OK, but really should fix...
   [ ] -1 I oppose this release because...


 -
 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: commit problem

[Kristian Rosenvold]

There may have been some infra related issues on this, you should try again

Kristian


2015-07-07 6:11 GMT+02:00 Kristian Rosenvold kristian.rosenv...@gmail.com:

 Maybe the committer email address is not your apache.org address ?

 Kristian
 6. jul. 2015 11.52 p.m. skrev Luc Maisonobe l...@spaceroots.org:

 Hi,

 I just get failures when pushing commits to [math] with an error message:


 pre-receive hook declined
 You are not authorized to edit this repository.

 Is there something wrong with our git repository?

 Luc

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

Re: commit problem

[Kristian Rosenvold]

Maybe the committer email address is not your apache.org address ?

Kristian
6. jul. 2015 11.52 p.m. skrev Luc Maisonobe l...@spaceroots.org:

 Hi,

 I just get failures when pushing commits to [math] with an error message:


 pre-receive hook declined
 You are not authorized to edit this repository.

 Is there something wrong with our git repository?

 Luc

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

Re: Wlcome to the Apache Commons PMC

[Kristian Rosenvold]

Thanks !

Now I just need to get down from the Norwegian mountains. I prefer them i
wintertime with lots of snow

Kristian
 4. jul. 2015 9.31 a.m. skrev Gary Gregory garydgreg...@gmail.com:

 Hi Kristian,

 Welcome to the Apache Commons PMC!

 Please read the following if you have not done already done so:

 http://apache.org/foundation/marks/responsibility.html

 You should now have access to the PMC-only parts of SVN for the project.

 Gary Gregory
 Apache Commons PMC Chair

 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second Edition
 http://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory

Re: [io] xml parser blues :)

[Kristian Rosenvold]

(sorry, wrong keyboard shortcut)

Invalid encoding name UTF_32BE.
org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 42; Invalid
encoding name UTF_32BE.
at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
at
org.apache.commons.io.input.BOMInputStreamTest.parseXml(BOMInputStreamTest.java:170)
at
org.apache.commons.io.input.BOMInputStreamTest.testReadXmlWithoutBOMUtf32Be(BOMInputStreamTest.java:208)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:88)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:228)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:74)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)

Does anyone have any clue as to how I can fix this ?

Kristian


2015-06-24 12:08 GMT+02:00 Kristian Rosenvold krosenv...@apache.org:

 BOMInputStreamTest#testReadXmlWithoutBOMUtf32Be and 3 others fail in
 site generation but not regular unit tests.

 I have identified that the problem is happening because
 xercesImpl/2.4.0/xercesImpl-2.4.0.jar is creeping in during site build

 With regular unit tests it picks up
 rt.jar!/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.class
 which seems to understand UTF_32BE. Upgrading to xercesImpl-2.11.0 does not
 seem to fix the problem either ?

 We're looking at:

[io] xml parser blues :)

[Kristian Rosenvold]

BOMInputStreamTest#testReadXmlWithoutBOMUtf32Be and 3 others fail in site
generation but not regular unit tests.

I have identified that the problem is happening because
xercesImpl/2.4.0/xercesImpl-2.4.0.jar is creeping in during site build

With regular unit tests it picks up
rt.jar!/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.class
which seems to understand UTF_32BE. Upgrading to xercesImpl-2.11.0 does not
seem to fix the problem either ?

We're looking at:

Re: [io] xml parser blues :)

[Kristian Rosenvold]

That worked like a charm, great stuff. Thanks a lot !

Kristian


2015-06-24 17:46 GMT+02:00 sebb seb...@gmail.com:

 I added the following to the surefire configuration section in the pom:

   classpathDependencyExcludes

 classpathDependencyExcludexerces:xercesImpl/classpathDependencyExclude
   /classpathDependencyExcludes

 This worked for me.


 On 24 June 2015 at 11:57, sebb seb...@gmail.com wrote:
  On 24 June 2015 at 11:09, Kristian Rosenvold krosenv...@apache.org
 wrote:
  (sorry, wrong keyboard shortcut)
 
  Invalid encoding name UTF_32BE.
  org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 42; Invalid
  encoding name UTF_32BE.
  at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
  at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
  at
 
 org.apache.commons.io.input.BOMInputStreamTest.parseXml(BOMInputStreamTest.java:170)
  at
 
 org.apache.commons.io.input.BOMInputStreamTest.testReadXmlWithoutBOMUtf32Be(BOMInputStreamTest.java:208)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at
 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
  at
 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:483)
  at
 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
  at
 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
  at
 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
  at
 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
  at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
  at
 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
  at
 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
  at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
  at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
  at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
  at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
  at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
  at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
  at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
  at
 
 com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:88)
  at
 
 com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:228)
  at
 com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:74)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at
 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
  at
 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:483)
  at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
 
  Does anyone have any clue as to how I can fix this ?
 
  Does it happen with all Java versions?
  What version of Maven are you using?
 
  Kristian
 
 
  2015-06-24 12:08 GMT+02:00 Kristian Rosenvold krosenv...@apache.org:
 
  BOMInputStreamTest#testReadXmlWithoutBOMUtf32Be and 3 others fail in
  site generation but not regular unit tests.
 
  I have identified that the problem is happening because
  xercesImpl/2.4.0/xercesImpl-2.4.0.jar is creeping in during site build
 
  With regular unit tests it picks up
 
 rt.jar!/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.class
  which seems to understand UTF_32BE. Upgrading to xercesImpl-2.11.0
 does not
  seem to fix the problem either ?
 
  We're looking at:
 
 
 
 
 

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

[io] Preparing for 2.5 release

[Kristian Rosenvold]

My personal itch list is getting very short, and includes the following
items:

@since tag checkup
https://issues.apache.org/jira/browse/IO-469
https://issues.apache.org/jira/browse/IO-481
Fix 4 testcases that fail (only) in site generation due to xml parser
issues.

My ambition is to fix these things during the next 2-3 days and start a
release sometime in the weekend. The 5 other unsolved issues currently
assigned to 2.5 will be moved to unscheduled.

I encourage anyone wanting to iterate issues or generally assess the state
of the release to plan some time to do so within the next days.

As usual, reality bites and will probably smash my estimated time scale to
bits.


Kristian

Re: [io] How picky about backward compatibility ?

[Kristian Rosenvold]

2015-06-23 18:08 GMT+02:00 sebb seb...@gmail.com:

 On 23 June 2015 at 08:54, Kristian Rosenvold
 kristian.rosenv...@gmail.com wrote:
  I think I'll go for the release-notes approach; given that we can find an
  appropriate technical solution.
 
  Right now I'm leaning towards simply changing the contract regarding
  close to always throw its own instance of IOException, with a second
  constructor for those wanting fine grained control. If one of the
 existing
  constructors is used, simply use a new IOException().

 I don't think that is appropriate for the ctor which takes an IOE.
 That should use an exception of the same class as the parameter, and
 not force the use of an actual IOE.


But we won't know how to construct any arbitrary subclass of an IOE ?

Kristian

Re: svn commit: r1686747 [1/3] - in /commons/proper/io/trunk/src: main/java/org/apache/commons/io/ main/java/org/apache/commons/io/filefilter/ main/java/org/apache/commons/io/input/ main/java/org/apac

[Kristian Rosenvold]

2015-06-23 18:11 GMT+02:00 sebb seb...@gmail.com:

  org.apache.commons.io.output.DeferredFileOutputStream#thresholdReached
  possible file handle leak upon exception
 

 Can you update the SVN log message accordingly?

Done



 
 
 
  Also looks like many of the checkstyle fixes are just line-wraps; I
  thought we allowed a longer line length?
  Screens tend to be used in landscape mode so it's easier to read code
  if is not wrapped unnecessarily
 
 
  Most of it is just feeding the OCD. 0 checkstyle errors is the one ring
 to
  rule them all :)
 
  Would it make sense to change the checkstyle column width to something
 like
  160 ?

 Or drop the rule entirely?

 I'm all in favour of anything 120 chars :)

Kristian

Re: [io] How picky about backward compatibility ?

[Kristian Rosenvold]

I think I'll go for the release-notes approach; given that we can find an
appropriate technical solution.

Right now I'm leaning towards simply changing the contract regarding
close to always throw its own instance of IOException, with a second
constructor for those wanting fine grained control. If one of the existing
constructors is used, simply use a new IOException().

Kristian

2015-06-22 20:06 GMT+02:00 Benedikt Ritter brit...@apache.org:

 2015-06-21 14:34 GMT+02:00 Kristian Rosenvold 
 kristian.rosenv...@gmail.com
 :

  2015-06-21 14:16 GMT+02:00 sebb seb...@gmail.com:
  
  
   Is there a genuine use-case which requires that the same IOE instance
   be used? (Other than the unit tests!)
   If not, then we could look into relaxing the behaviour (and fixing the
   Javadoc) for a future release.
   If there is a use-case for always using the same instance, then
   providing an additional ctor would work.
  
  
  As far as I can understand the entire use case for this class is for
  testing purposes. hashCode/equals for IOException use the Object
 version.
  So any client code that uses == or equals on the thrown exception will
  fail. But I really believe this class is designed to provoke a specific
  exception behaviour in a testcase. I am not entirely convinced there is
  much real-life code that actually would assertSame or assertEquals on the
  actual exception thrown. So my personal preference is basically to make
 it
  a documented behavioural change.
 

 +1, we've done this in the past by introducing the RELEASE-NOTES.txt with a
 NOTICE or COMPATIBILITY section that elaborates about the changes. See for
 example the Lang 3.4 release notes [1]

 Benedikt

 [1]

 http://commons.apache.org/proper/commons-lang/release-notes/RELEASE-NOTES-3.4.txt


 
  Kristian
 



 --
 http://people.apache.org/~britter/
 http://www.systemoutprintln.de/
 http://twitter.com/BenediktRitter
 http://github.com/britter

Re: Jira permissions gone .. ?

[Kristian Rosenvold]

Yup, they're back. Still need other permissions to actually do RM work
though...

K
22. jun. 2015 8.00 p.m. skrev Benedikt Ritter brit...@apache.org:

 Hello again,

 looks like you have been removed from the commons-developer group. I've
 added you again. Does it work?

 Benedikt

 2015-06-22 19:53 GMT+02:00 Benedikt Ritter brit...@apache.org:

  Hello Kristian,
 
  sorry for the late reply. I'll have a look.
 
  Benedikt
 
  2015-06-19 19:06 GMT+02:00 Kristian Rosenvold krosenv...@apache.org:
 
  I seem to have lost my jira permissions to assign issues to myself and
  close them. I believe I had them not so long ago... ?
 
  Kristian (krosenvold)
 
 
 
 
  --
  http://people.apache.org/~britter/
  http://www.systemoutprintln.de/
  http://twitter.com/BenediktRitter
  http://github.com/britter
 



 --
 http://people.apache.org/~britter/
 http://www.systemoutprintln.de/
 http://twitter.com/BenediktRitter
 http://github.com/britter

Re: svn commit: r1686472 - in /commons/proper/io/trunk/src: main/java/org/apache/commons/io/FileUtils.java main/java/org/apache/commons/io/Java7Support.java test/java/org/apache/commons/io/FileUtilsCl

[Kristian Rosenvold]

2015-06-21 16:14 GMT+02:00 sebb seb...@gmail.com:


  But there is no unnecessary unboxing here, hence no bug.

 Exactly, so the IntelliJ warning is wrong.

 No. I added the redundant call back since that's the way you seem to
prefer round here.

Kristian

Re: [io] How picky about backward compatibility ?

[Kristian Rosenvold]

2015-06-21 14:16 GMT+02:00 sebb seb...@gmail.com:


 Is there a genuine use-case which requires that the same IOE instance
 be used? (Other than the unit tests!)
 If not, then we could look into relaxing the behaviour (and fixing the
 Javadoc) for a future release.
 If there is a use-case for always using the same instance, then
 providing an additional ctor would work.


As far as I can understand the entire use case for this class is for
testing purposes. hashCode/equals for IOException use the Object version.
So any client code that uses == or equals on the thrown exception will
fail. But I really believe this class is designed to provoke a specific
exception behaviour in a testcase. I am not entirely convinced there is
much real-life code that actually would assertSame or assertEquals on the
actual exception thrown. So my personal preference is basically to make it
a documented behavioural change.

Kristian

Re: svn commit: r1686472 - in /commons/proper/io/trunk/src: main/java/org/apache/commons/io/FileUtils.java main/java/org/apache/commons/io/Java7Support.java test/java/org/apache/commons/io/FileUtilsCl

[Kristian Rosenvold]

2015-06-21 13:43 GMT+02:00 sebb seb...@gmail.com:


  I'm not sure I understand; the equivalent of
 
  Boolean result = (Boolean) isSymbolicLink.invoke(null, path);
  return result.booleanValue();
 
  Gives a style warning (uneccssary unboxing) in IntelliJ.

 That warning is wrong.

 Unboxing is clearly necessary here; it's just a question of whether it
 is implicit or explicit.

 I have seen several cases where implicit boxing was associated with a code
 bug.
 For example, a local variable was defined as Boolean but always used as
 boolean.


This makes me curious; the only bug I know of in this context is the clasic
NPE you can get in the automatic unboxing. Is there some other scenario
you're thinking of ?  (Uneccessary object allocation is obvious and
something we try to avoid but hardly a bug. In this case I also think the
object is unavoidable...)

Kristian

Re: svn commit: r1686472 - in /commons/proper/io/trunk/src: main/java/org/apache/commons/io/FileUtils.java main/java/org/apache/commons/io/Java7Support.java test/java/org/apache/commons/io/FileUtilsCl

[Kristian Rosenvold]

2015-06-21 13:43 GMT+02:00 sebb seb...@gmail.com:

 Final variables are guaranteed to be safely published across threads.
 Is that true for non-final variables if they are established in a static
 block?


Yes. All static blocks are guranteed to be visible (all class
initialization is basically a synchronized operation for that class) and as
long as they're effectively immutable it does not really matter. Style wise
I would personally also prefer to make them final, but that would actually
increase the overall footprint of the code somewhat (believe me, I tried
when I initially wrote this code...)

So I think this code is nicer, but it's really only a very subtle
preference and I'm definitely not married to this way of doing it :)


  Boolean result = (Boolean) isSymbolicLink.invoke(null, path);
  return result.booleanValue();
 
  Gives a style warning (uneccssary unboxing) in IntelliJ.

 That warning is wrong.


 Unboxing is clearly necessary here; it's just a question of whether it
 is implicit or explicit.


 I have seen several cases where implicit boxing was associated with a code
 bug.
 For example, a local variable was defined as Boolean but always used as
 boolean.

 So I always set Eclipse to warn where implicit (un)boxing is occurring.
 Yes, it requires a bit more work by the developer, but it ensures that
 the (un)boxing really is intentional.

  Is there some other mechanism you're thinking of ?

 No.

 
  Kristian

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

Re: svn commit: r1686472 - in /commons/proper/io/trunk/src: main/java/org/apache/commons/io/FileUtils.java main/java/org/apache/commons/io/Java7Support.java test/java/org/apache/commons/io/FileUtilsCl

[Kristian Rosenvold]

2015-06-21 14:53 GMT+02:00 sebb seb...@gmail.com:

 On 21 June 2015 at 13:24, Kristian Rosenvold
 kristian.rosenv...@gmail.com wrote:
  2015-06-21 13:43 GMT+02:00 sebb seb...@gmail.com:
 
 
   I'm not sure I understand; the equivalent of
  
   Boolean result = (Boolean) isSymbolicLink.invoke(null, path);
   return result.booleanValue();
  
   Gives a style warning (uneccssary unboxing) in IntelliJ.
 
  That warning is wrong.
 
  Unboxing is clearly necessary here; it's just a question of whether it
  is implicit or explicit.
 
  I have seen several cases where implicit boxing was associated with a
 code
  bug.
  For example, a local variable was defined as Boolean but always used as
  boolean.
 
 
  This makes me curious; the only bug I know of in this context is the
 clasic
  NPE you can get in the automatic unboxing. Is there some other scenario
  you're thinking of ?  (Uneccessary object allocation is obvious and
  something we try to avoid but hardly a bug. In this case I also think the
  object is unavoidable...)

 IMO it is a bug to write code that uses unnecessary (un)boxing.
 Not a very serious bug in general, though it might well have a
 performance impact if done repeatedly.


But there is no unnecessary unboxing here, hence no bug. I work on way too
many projects with way too many code styles to care about arguing these
matters. If old-style explicit unboxing is how you want it around here,
that's what I'll write.



 There was another scenario which I came across a while ago.
 Unfortunately I did not keep a note of it, but IIRC it was not just a
 performance/NPE issue


That would be interesting to hear about if you remember. Selection of
different overloads is the only one I can think of.

Kristian

Re: svn commit: r1686747 [1/3] - in /commons/proper/io/trunk/src: main/java/org/apache/commons/io/ main/java/org/apache/commons/io/filefilter/ main/java/org/apache/commons/io/input/ main/java/org/apac

[Kristian Rosenvold]

2015-06-22 2:53 GMT+02:00 sebb seb...@gmail.com:

 What was the Findbugs error?

 Best not to mix these in a single commit.

Sorry about that.

org.apache.commons.io.output.DeferredFileOutputStream#thresholdReached
possible file handle leak upon exception




 Also looks like many of the checkstyle fixes are just line-wraps; I
 thought we allowed a longer line length?
 Screens tend to be used in landscape mode so it's easier to read code
 if is not wrapped unnecessarily


Most of it is just feeding the OCD. 0 checkstyle errors is the one ring to
rule them all :)

Would it make sense to change the checkstyle column width to something like
160 ?

Kristian

[io] svn commit r1686512

[Kristian Rosenvold]

I reverted some of the package protected - private changes, since the
tests did not even compile with this change.

Kristian

[io] How picky about backward compatibility ?

[Kristian Rosenvold]

I reverted the fix in
http://svn.apache.org/viewvc?view=revisionrevision=r1686456 simply because
it broke backward compatibility in a subtle way. The BrokenNNStream classes
supply the same instance of the IOException on all methods (and there are
tests that assert it)

Given some of the discussions I've seen about backward compatibility here,
I felt it best to revert (even though API-wise I feel this change is within
reasonable even for a minor release). WDYT ?

Kristian

Jira permissions gone .. ?

[Kristian Rosenvold]

I seem to have lost my jira permissions to assign issues to myself and
close them. I believe I had them not so long ago... ?

Kristian (krosenvold)

Re: [jira] [Created] (IO-481) org.apache.commons.io.FileUtils#waitFor waits too long

[Kristian Rosenvold]

No, I just created a regular issue like a regular guy from the street. I
cant assign issues to me or close issues as fixed.

Kristian


2015-06-19 20:21 GMT+02:00 Gary Gregory garydgreg...@gmail.com:

 Kristian,

 It looks like you've solved your Jira admin issues :-)

 Gary

 -- Forwarded message --
 From: Kristian Rosenvold (JIRA) j...@apache.org
 Date: Fri, Jun 19, 2015 at 11:20 AM
 Subject: [jira] [Created] (IO-481) org.apache.commons.io.FileUtils#waitFor
 waits too long
 To: iss...@commons.apache.org


 Kristian Rosenvold created IO-481:
 -

  Summary: org.apache.commons.io.FileUtils#waitFor waits too
 long
  Key: IO-481
  URL: https://issues.apache.org/jira/browse/IO-481
  Project: Commons IO
   Issue Type: Bug
 Affects Versions: 2.4
 Reporter: Kristian Rosenvold


 The timing algorithm is basically broken, since Thread.sleep is imprecise.
 There is also a counter error in the looping code.

 The following testcase will never run in less than 4 seconds on my machine

   public void testRealWallTime() {
 long start = System.currentTimeMillis();
 FileUtils.waitFor(new File(), 2);
 System.out.println(elapsed =  + (System.currentTimeMillis() -
 start));
 }



 --
 This message was sent by Atlassian JIRA
 (v6.3.4#6332)



 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second Edition
 http://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory

Re: svn commit: r1686260 [1/5] - in /commons/proper/io/trunk/src: main/java/org/apache/commons/io/ main/java/org/apache/commons/io/input/ main/java/org/apache/commons/io/monitor/ test/java/org/apache/

[Kristian Rosenvold]

We (maven) /just/ managed to switch to 1.6 baseline. So I'm +1 for making
at least one more release with 1.6 ;)

Kristian


2015-06-18 18:16 GMT+02:00 Gary Gregory garydgreg...@gmail.com:

 On Thu, Jun 18, 2015 at 8:57 AM, krosenv...@apache.org wrote:

  Author: krosenvold
  Date: Thu Jun 18 15:57:56 2015
  New Revision: 1686260
 
  URL: http://svn.apache.org/r1686260
  Log:
  Language level code changes
 
 
  ...


 
  Modified:
 
 commons/proper/io/trunk/src/main/java/org/apache/commons/io/FileSystemUtils.java
  URL:
 
 http://svn.apache.org/viewvc/commons/proper/io/trunk/src/main/java/org/apache/commons/io/FileSystemUtils.java?rev=1686260r1=1686259r2=1686260view=diff
 
 
 ==
  ---
 
 commons/proper/io/trunk/src/main/java/org/apache/commons/io/FileSystemUtils.java
  (original)
  +++
 
 commons/proper/io/trunk/src/main/java/org/apache/commons/io/FileSystemUtils.java
  Thu Jun 18 15:57:56 2015
  @@ -75,23 +75,23 @@ public class FileSystemUtils {
   }
   osName = osName.toLowerCase(Locale.ENGLISH);
   // match
  -if (osName.indexOf(windows) != -1) {
  +if (osName.contains(windows)) {
   os = WINDOWS;
  -} else if (osName.indexOf(linux) != -1 ||
  -osName.indexOf(mpe/ix) != -1 ||
  -osName.indexOf(freebsd) != -1 ||
  -osName.indexOf(irix) != -1 ||
  -osName.indexOf(digital unix) != -1 ||
  -osName.indexOf(unix) != -1 ||
  -osName.indexOf(mac os x) != -1) {
  +} else if (osName.contains(linux) ||
  +osName.contains(mpe/ix) ||
  +osName.contains(freebsd) ||
  +osName.contains(irix) ||
  +osName.contains(digital unix) ||
  +osName.contains(unix) ||
  +osName.contains(mac os x)) {
   os = UNIX;
  -} else if (osName.indexOf(sun os) != -1 ||
  -osName.indexOf(sunos) != -1 ||
  -osName.indexOf(solaris) != -1) {
  +} else if (osName.contains(sun os) ||
  +osName.contains(sunos) ||
  +osName.contains(solaris)) {
   os = POSIX_UNIX;
   dfPath = /usr/xpg4/bin/df;
  -} else if (osName.indexOf(hp-ux) != -1 ||
  -osName.indexOf(aix) != -1) {
  +} else if (osName.contains(hp-ux) ||
  +osName.contains(aix)) {
   os = POSIX_UNIX;
   } else {
   os = OTHER;
 
 
 
 How about finally updating [io] to Java 7 and using a switch?

 Gary


 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second Edition
 http://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory

Re: svn commit: r1686260 [1/5] - in /commons/proper/io/trunk/src: main/java/org/apache/commons/io/ main/java/org/apache/commons/io/input/ main/java/org/apache/commons/io/monitor/ test/java/org/apache/

[Kristian Rosenvold]

I can do the release, but I'm not entirely sure I'd have the necessary
priveiliges (since I'm not even a committer in commons). Then again I might
have them since I'm a member, I'm a bit unsure :) I suspect nexus wont let
me deploy...

Kristian


2015-06-18 18:50 GMT+02:00 Gary Gregory garydgreg...@gmail.com:

 [io] needs a release bad, it's been way to long. I can live with 1.6 for a
 release if is soon. Then switch to Java 7.

 Are you willing to RM?

 Gary

 On Thu, Jun 18, 2015 at 9:28 AM, Kristian Rosenvold krosenv...@apache.org
 
 wrote:

  We (maven) /just/ managed to switch to 1.6 baseline. So I'm +1 for making
  at least one more release with 1.6 ;)
 
  Kristian
 
 
  2015-06-18 18:16 GMT+02:00 Gary Gregory garydgreg...@gmail.com:
 
   On Thu, Jun 18, 2015 at 8:57 AM, krosenv...@apache.org wrote:
  
Author: krosenvold
Date: Thu Jun 18 15:57:56 2015
New Revision: 1686260
   
URL: http://svn.apache.org/r1686260
Log:
Language level code changes
   
   
...
  
  
   
Modified:
   
  
 
 commons/proper/io/trunk/src/main/java/org/apache/commons/io/FileSystemUtils.java
URL:
   
  
 
 http://svn.apache.org/viewvc/commons/proper/io/trunk/src/main/java/org/apache/commons/io/FileSystemUtils.java?rev=1686260r1=1686259r2=1686260view=diff
   
   
  
 
 ==
---
   
  
 
 commons/proper/io/trunk/src/main/java/org/apache/commons/io/FileSystemUtils.java
(original)
+++
   
  
 
 commons/proper/io/trunk/src/main/java/org/apache/commons/io/FileSystemUtils.java
Thu Jun 18 15:57:56 2015
@@ -75,23 +75,23 @@ public class FileSystemUtils {
 }
 osName = osName.toLowerCase(Locale.ENGLISH);
 // match
-if (osName.indexOf(windows) != -1) {
+if (osName.contains(windows)) {
 os = WINDOWS;
-} else if (osName.indexOf(linux) != -1 ||
-osName.indexOf(mpe/ix) != -1 ||
-osName.indexOf(freebsd) != -1 ||
-osName.indexOf(irix) != -1 ||
-osName.indexOf(digital unix) != -1 ||
-osName.indexOf(unix) != -1 ||
-osName.indexOf(mac os x) != -1) {
+} else if (osName.contains(linux) ||
+osName.contains(mpe/ix) ||
+osName.contains(freebsd) ||
+osName.contains(irix) ||
+osName.contains(digital unix) ||
+osName.contains(unix) ||
+osName.contains(mac os x)) {
 os = UNIX;
-} else if (osName.indexOf(sun os) != -1 ||
-osName.indexOf(sunos) != -1 ||
-osName.indexOf(solaris) != -1) {
+} else if (osName.contains(sun os) ||
+osName.contains(sunos) ||
+osName.contains(solaris)) {
 os = POSIX_UNIX;
 dfPath = /usr/xpg4/bin/df;
-} else if (osName.indexOf(hp-ux) != -1 ||
-osName.indexOf(aix) != -1) {
+} else if (osName.contains(hp-ux) ||
+osName.contains(aix)) {
 os = POSIX_UNIX;
 } else {
 os = OTHER;
   
   
   
   How about finally updating [io] to Java 7 and using a switch?
  
   Gary
  
  
   --
   E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
   Java Persistence with Hibernate, Second Edition
   http://www.manning.com/bauer3/
   JUnit in Action, Second Edition http://www.manning.com/tahchiev/
   Spring Batch in Action http://www.manning.com/templier/
   Blog: http://garygregory.wordpress.com
   Home: http://garygregory.com/
   Tweet! http://twitter.com/GaryGregory
  
 



 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second Edition
 http://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory

Re: svn commit: r1686260 [1/5] - in /commons/proper/io/trunk/src: main/java/org/apache/commons/io/ main/java/org/apache/commons/io/input/ main/java/org/apache/commons/io/monitor/ test/java/org/apache/

[Kristian Rosenvold]

I know about the new policy, I've been using it in compress :)

 I'm still not entirely sure I'd be able to stage a release in nexus :)

But time will tell; I have 30 some issues on my triage list right now. I
was planning to start that a few weeks ago but I had so many other yaks to
shave.

Kristian


2015-06-18 19:17 GMT+02:00 Gary Gregory garydgreg...@gmail.com:

 We implemented a new policy a couple of months ago: All Apache Committer
 can commit to Apache Commons! Pretty cool eh?

 But a PMC member might need to do some tasks, I'm not sure about that one.

 Gary

 On Thu, Jun 18, 2015 at 10:04 AM, Kristian Rosenvold 
 krosenv...@apache.org
 wrote:

  I can do the release, but I'm not entirely sure I'd have the necessary
  priveiliges (since I'm not even a committer in commons). Then again I
 might
  have them since I'm a member, I'm a bit unsure :) I suspect nexus wont
 let
  me deploy...
 
  Kristian
 
 
  2015-06-18 18:50 GMT+02:00 Gary Gregory garydgreg...@gmail.com:
 
   [io] needs a release bad, it's been way to long. I can live with 1.6
 for
  a
   release if is soon. Then switch to Java 7.
  
   Are you willing to RM?
  
   Gary
  
   On Thu, Jun 18, 2015 at 9:28 AM, Kristian Rosenvold 
  krosenv...@apache.org
   
   wrote:
  
We (maven) /just/ managed to switch to 1.6 baseline. So I'm +1 for
  making
at least one more release with 1.6 ;)
   
Kristian
   
   
2015-06-18 18:16 GMT+02:00 Gary Gregory garydgreg...@gmail.com:
   
 On Thu, Jun 18, 2015 at 8:57 AM, krosenv...@apache.org wrote:

  Author: krosenvold
  Date: Thu Jun 18 15:57:56 2015
  New Revision: 1686260
 
  URL: http://svn.apache.org/r1686260
  Log:
  Language level code changes
 
 
  ...


 
  Modified:
 

   
  
 
 commons/proper/io/trunk/src/main/java/org/apache/commons/io/FileSystemUtils.java
  URL:
 

   
  
 
 http://svn.apache.org/viewvc/commons/proper/io/trunk/src/main/java/org/apache/commons/io/FileSystemUtils.java?rev=1686260r1=1686259r2=1686260view=diff
 
 

   
  
 
 ==
  ---
 

   
  
 
 commons/proper/io/trunk/src/main/java/org/apache/commons/io/FileSystemUtils.java
  (original)
  +++
 

   
  
 
 commons/proper/io/trunk/src/main/java/org/apache/commons/io/FileSystemUtils.java
  Thu Jun 18 15:57:56 2015
  @@ -75,23 +75,23 @@ public class FileSystemUtils {
   }
   osName = osName.toLowerCase(Locale.ENGLISH);
   // match
  -if (osName.indexOf(windows) != -1) {
  +if (osName.contains(windows)) {
   os = WINDOWS;
  -} else if (osName.indexOf(linux) != -1 ||
  -osName.indexOf(mpe/ix) != -1 ||
  -osName.indexOf(freebsd) != -1 ||
  -osName.indexOf(irix) != -1 ||
  -osName.indexOf(digital unix) != -1 ||
  -osName.indexOf(unix) != -1 ||
  -osName.indexOf(mac os x) != -1) {
  +} else if (osName.contains(linux) ||
  +osName.contains(mpe/ix) ||
  +osName.contains(freebsd) ||
  +osName.contains(irix) ||
  +osName.contains(digital unix) ||
  +osName.contains(unix) ||
  +osName.contains(mac os x)) {
   os = UNIX;
  -} else if (osName.indexOf(sun os) != -1 ||
  -osName.indexOf(sunos) != -1 ||
  -osName.indexOf(solaris) != -1) {
  +} else if (osName.contains(sun os) ||
  +osName.contains(sunos) ||
  +osName.contains(solaris)) {
   os = POSIX_UNIX;
   dfPath = /usr/xpg4/bin/df;
  -} else if (osName.indexOf(hp-ux) != -1 ||
  -osName.indexOf(aix) != -1) {
  +} else if (osName.contains(hp-ux) ||
  +osName.contains(aix)) {
   os = POSIX_UNIX;
   } else {
   os = OTHER;
 
 
 
 How about finally updating [io] to Java 7 and using a switch?

 Gary


 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second Edition
 http://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory

   
  
  
  
   --
   E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
   Java Persistence with Hibernate, Second Edition
   http

Re: [io] Is commons-io dormant?

[Kristian Rosenvold]

I'll spend some time this weekend iterating over issues for io and apply
patches that appear appropriate and uncontroversial.

Kristian


2015-05-11 7:57 GMT+02:00 Benedikt Ritter brit...@apache.org:

 I'll be on vacation the next week. I could do it in two weeks at the
 earliest.

 Benedikt

 2015-05-11 5:26 GMT+02:00 Gary Gregory garydgreg...@gmail.com:

  Hello, it is not dormant. It's just that no one has volunteered to cut a
  release candidate. The component is due for a refresh. I did not realize
 it
  had been so long since a release.
  Any volunteers?
 
  Gary
 
   Original message 
  From: Kervin Pierre ker...@sludev.com
  Date: 05/10/2015  18:20  (GMT-06:00)
  To: dev@commons.apache.org
  Subject: [io] Is commons-io dormant?
 
  Hi,
 
  The last snapshot ( 2.5-SNAPSHOT ) seems to be over a year old, and last
  release 2.4 was in 2012 ( I believe, please correct me if I'm wrong ).
 
  I started using its Tailer class in 2.4 and realized there are a few
  bugs.  Some are fixed over a year now in SVN.  E.g. commons-io 2.4
  version swallows InterruptException.  For a class that blocks most of
  its life that's very inconvenient when trying to shutdown the thread.
  Also there are fixes relating to
  https://issues.apache.org/jira/browse/IO-279 which although aren't
  entirely fixed, have been made much better but are only in the snapshot.
 
  So is commons-io dormant?  Is there something users can do to help if
  it's a time-resource issue?
 
  Best regards,
  Kervin
  ​​​
 



 --
 http://people.apache.org/~britter/
 http://www.systemoutprintln.de/
 http://twitter.com/BenediktRitter
 http://github.com/britter

Re: [io] Is commons-io dormant?

[Kristian Rosenvold]

2015-05-12 23:09 GMT+02:00 Kervin Pierre ker...@sludev.com:

 I'd like to help if possible.  What would be involved?


There is an abundance of issues in Jira that should be triaged somewhat
before pushing a release. You can fix issues without patches, review
existing patches and/or comment on issues. Looking through the open issues
it would appear some of them should also be closed or at least moved out of
IO.

Given that people with committ access *will* be triaging through the
current unsolved issues in the next week or two, this is a great time to
chip in :)

Kristian

Re: [LANG] Add ThreadUtils

[Kristian Rosenvold]

If think later (in 2025 :-) you just make interface ThreadPredicate
extend java.util.function.Predicate.

Kristian


2015-04-12 13:14 GMT+02:00 Benedikt Ritter benerit...@gmail.com:
 Hi,

 there is currently a discussion on github about the addition of a low level 
 utility class which helps to retrieve Threads [1]. The latest proposal is to 
 implement a predicate based approach for filtering threads [2]. My opinion 
 is, that we should not add such an API at all, because we would have to 
 revert it anyway, when we upgrade [lang] to Java 8. Further more I don't 
 think it is a good idea to add a generic Pedicate interface to [lang]. This 
 will only cause confusion for users already using Java 8. So if we really 
 want to add predicate based API in ThreadUtils, it should IMHO Look like this:

 CollectionThread ThreadUtils.findThreads(ThreadPredicate filter)

 public interface ThreadPredicate {
boolean test(Thread);
 }

 Later we can change this to:

 CollectionThread 
 ThreadUtils.findThreads(java.util.function.PredicateThread filter)

 public interface ThreadPredicate extends java.util.function.PredicateThread

 I'd like to hear what others think about this.

 Regards,
 Benedikt

 [1] https://github.com/apache/commons-lang/pull/61
 [2] https://github.com/salyh/commons-lang/pull/1

 Send from my mobile device
 -
 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 Compress 1.10 Based on RC1

[Kristian Rosenvold]

I've run through all of our tests and the release looks good.

The testcase should fail 1 in 1000 times as is and has been fixed.

I'm +1 on the release as such (but we'd normally recut or leave this
decision to the RM).

Krisian

2015-01-27 7:35 GMT+01:00 Kristian Rosenvold kristian.rosenv...@gmail.com:
 Done in r1654980.

 This whole incident is a confirmation of murphys law; I must've run
 that test 500 times on my machine without failure =:)

 K


 2015-01-27 0:10 GMT+01:00 Gary Gregory garydgreg...@gmail.com:
 I see you changed the test but the code could benefit from a comment to
 avoid a future regression back to this problem.

 Gary

 On Mon, Jan 26, 2015 at 4:52 PM, Kristian Rosenvold krosenv...@apache.org
 wrote:

 Testcase fixed in r1654901

 Kristian


 2015-01-26 22:37 GMT+01:00 Kristian Rosenvold 
 kristian.rosenv...@gmail.com:
  2015-01-26 22:27 GMT+01:00 Gary Gregory garydgreg...@gmail.com:
  Tests:
 
  Running: 'mvn clean site' gave me
 
  Failed tests:
 
  ZipTestCase.testCopyRawZip64EntryFromFile:361-assertSameFileContents:414
  arrays first differed at element [10]; expected:-16 but was:-15
 
  The problem appears to be that time does not stand still, and every
  now and then you can make expected and actual get different time
  stamps (with the 2 second granularity of zip it takes a bit of luck
  to hit the problem)
 
  The problem is within the testcase itself, and I'll fix this on trunk.
 
  Kristian

 -
 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
 http://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 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: [VOTE] Release Compress 1.10 Based on RC1

[Kristian Rosenvold]

2015-01-27 15:24 GMT+01:00 Gary Gregory garydgreg...@gmail.com:

 I'd prefer a clean RC to give a positive vote. So I'll abstain for now.

That seems to be the norm :)

K

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

Re: [VOTE] Release Compress 1.10 Based on RC1

[Kristian Rosenvold]

2015-01-26 22:27 GMT+01:00 Gary Gregory garydgreg...@gmail.com:
 Tests:

 Running: 'mvn clean site' gave me

 Failed tests:
   ZipTestCase.testCopyRawZip64EntryFromFile:361-assertSameFileContents:414
 arrays first differed at element [10]; expected:-16 but was:-15

The problem appears to be that time does not stand still, and every
now and then you can make expected and actual get different time
stamps (with the 2 second granularity of zip it takes a bit of luck
to hit the problem)

The problem is within the testcase itself, and I'll fix this on trunk.

Kristian

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

Re: [VOTE] Release Compress 1.10 Based on RC1

[Kristian Rosenvold]

Done in r1654980.

This whole incident is a confirmation of murphys law; I must've run
that test 500 times on my machine without failure =:)

K


2015-01-27 0:10 GMT+01:00 Gary Gregory garydgreg...@gmail.com:
 I see you changed the test but the code could benefit from a comment to
 avoid a future regression back to this problem.

 Gary

 On Mon, Jan 26, 2015 at 4:52 PM, Kristian Rosenvold krosenv...@apache.org
 wrote:

 Testcase fixed in r1654901

 Kristian


 2015-01-26 22:37 GMT+01:00 Kristian Rosenvold 
 kristian.rosenv...@gmail.com:
  2015-01-26 22:27 GMT+01:00 Gary Gregory garydgreg...@gmail.com:
  Tests:
 
  Running: 'mvn clean site' gave me
 
  Failed tests:
 
  ZipTestCase.testCopyRawZip64EntryFromFile:361-assertSameFileContents:414
  arrays first differed at element [10]; expected:-16 but was:-15
 
  The problem appears to be that time does not stand still, and every
  now and then you can make expected and actual get different time
  stamps (with the 2 second granularity of zip it takes a bit of luck
  to hit the problem)
 
  The problem is within the testcase itself, and I'll fix this on trunk.
 
  Kristian

 -
 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
 http://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 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: [VOTE] Release Compress 1.10 Based on RC1

[Kristian Rosenvold]

Testcase fixed in r1654901

Kristian


2015-01-26 22:37 GMT+01:00 Kristian Rosenvold kristian.rosenv...@gmail.com:
 2015-01-26 22:27 GMT+01:00 Gary Gregory garydgreg...@gmail.com:
 Tests:

 Running: 'mvn clean site' gave me

 Failed tests:
   ZipTestCase.testCopyRawZip64EntryFromFile:361-assertSameFileContents:414
 arrays first differed at element [10]; expected:-16 but was:-15

 The problem appears to be that time does not stand still, and every
 now and then you can make expected and actual get different time
 stamps (with the 2 second granularity of zip it takes a bit of luck
 to hit the problem)

 The problem is within the testcase itself, and I'll fix this on trunk.

 Kristian

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

Re: [compress] Preparations for 1.10

[Kristian Rosenvold]

After an intense few minutes discussing the color of the bike shed
with myself (package name) I moved the zip-unspecific parallel stuff
to org.apache.commons.compress.parallel in r1654572. This concludes
the changes Emmanuel suggested. I have already responded to a few of
the comments that did not lead to code change; if anyone wants to
discuss these matters further now would be a good time :)

I also further refined some javadocs a bit; I'll be reading through
the full site for the new stuff once more tonight.

I suppose the what's new section on the site also needs to be
updated to 1.10 ?

Anything else I can assist with before the release ?

Kristian






2015-01-24 13:18 GMT+01:00 Stefan Bodewig bode...@apache.org:
 On 2015-01-23, Emmanuel Bourg wrote:

 Le 22/01/2015 17:30, Stefan Bodewig a écrit :

 Please have a look and identify stuff that looks as if I'd have to
 reroll a new RC should it come to a vote with the current code base.

 I reviewed the API changes, here are my comments:

 - PasswordRequiredException: the exception is in the sevenz package, do
 we want to move it elsewhere so it can be used later for other formats
 like zip (if that makes sense).

 Moved to a new exceptions package.

 - BitInputStream: why not using a long cache instead of an int, like
 BitStream before the refactoring? It might be interesting to do some
 benchmarks and see if it make a difference.

 We never needed more than 31 bits, but you are right, I'll try to
 experiment a little.

 Stefan

 -
 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: [compress] Preparations for 1.10

[Kristian Rosenvold]

2015-01-23 11:52 GMT+01:00 Emmanuel Bourg ebo...@apache.org:

 - PasswordRequiredException: the exception is in the sevenz package, do
 we want to move it elsewhere so it can be used later for other formats
 like zip (if that makes sense).

Makes sense, where should we put that ?

 - there are some missing @since tags on the new classes
 (ScatterGatherBackingStoreSupplier, ParallelScatterZipCreator,
 InputStreamSupplier, ZipArchiveEntryRequest, ZipArchiveEntryPredicate)

Fixed r1654291

 - InputStreamSupplier could have been replaced with
 SupplierInputStream if we were using Java 8. But with the current JDK
 I wonder if we could use CallableInputStream instead to spare an
 interface.

Discussed in separate mail; leaving as-is for now.


 - If we had a kind of DeferredInputStream (not yet in commons-io sadly)
 the API could be slightly simpler. ZipArchiveEntryRequest and
 InputStreamSupplier could go away. DeferredInputStream would open an
 underlying stream only when a read() method is called.

I think the overall memory model constraints in a parallel context
favour the Supplier approach, since you avoid the entire need for a
thread-safe DeferredInputStream.

 - ParallelScatterZipCreator has two public methods with a
 CallableObject in the signature, but it's not clear what this Object
 actually is.

Fixed in r1654291


 - Is ParallelScatterZipCreator.getStatisticsMessage() intended to remain
 in the final API or was it just there for benchmarking the
 implementation during the development? If it is meant to stay maybe a
 proper ScatterStatistics class would be cleaner.

Introduced class in r1654291

 - ParallelScatterZipCreator.createCallable: the message of the
 IllegalArgumentException could mention the name of the entry involved.

Also fixed.

 - The javadoc of the default ParallelScatterZipCreator constructor could
 explain how the thread pool is sized by default.

Also fixed.

 - Could ScatterGatherBackingStoreSupplier be avoided? The public
 ParallelScatterZipCreator constructor that uses it could accept a
 ScatterGatherBackingStore instead, we would just have to ensure that the
 backing store doesn't open resources until it's used.

Concurrent running creates multiple instances, so that won't work.

 - ScatterGatherBackingStore, FileBasedScatterGatherBackingStore and
 ScatterGatherBackingStoreSupplier are in the zip package but have
 nothing specific to the zip format. Should we move them elsewhere so
 they can be used later to implement parallel compression for other formats?

Good idea; something like org.apache.commons.compress.archivers.concurrent or
org.apache.commons.compress.concurrent ?

 - I think an example demonstrating the parallel zip creation would be a
 nice addition to the site.

I'll add some code later tonight.

Thanks a lot for some great comments !

Kristian

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

Re: [ALL] JIRA permissions for Kristian Rosenvold

[Kristian Rosenvold]

Sorry; all is ok. The asf jira has a slightly different config than
the one I'm used to.

Kristian


2015-01-23 10:46 GMT+01:00 Kristian Rosenvold krosenv...@apache.org:
 Can you check that you did the right thing, Mark ? It seems like I
 have even less permissions now; I can't even edit own issues any
 more...?

 Kristian


 2015-01-23 10:13 GMT+01:00 Mark Thomas ma...@apache.org:
 On 23/01/2015 09:10, Stefan Bodewig wrote:
 On 2015-01-23, luc wrote:

 Le 2015-01-23 04:00, sebb a écrit :
 On 22 January 2015 at 23:55, sebb seb...@gmail.com wrote:
 On 20 January 2015 at 16:26, Stefan Bodewig bode...@apache.org
 wrote:

 JIRA Admins for Commons are Phil, Luc and Mark Struberg.

 Wrong Mark.

 I've just added Kristian to the Committer, Contributor, Developer and
 User roles for the Commons Category (which should include all Commons
 components).

 Mark



 -
 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] JIRA permissions for Kristian Rosenvold

[Kristian Rosenvold]

Can you check that you did the right thing, Mark ? It seems like I
have even less permissions now; I can't even edit own issues any
more...?

Kristian


2015-01-23 10:13 GMT+01:00 Mark Thomas ma...@apache.org:
 On 23/01/2015 09:10, Stefan Bodewig wrote:
 On 2015-01-23, luc wrote:

 Le 2015-01-23 04:00, sebb a écrit :
 On 22 January 2015 at 23:55, sebb seb...@gmail.com wrote:
 On 20 January 2015 at 16:26, Stefan Bodewig bode...@apache.org
 wrote:

 JIRA Admins for Commons are Phil, Luc and Mark Struberg.

 Wrong Mark.

 I've just added Kristian to the Committer, Contributor, Developer and
 User roles for the Commons Category (which should include all Commons
 components).

 Mark



 -
 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: [compress] Preparations for 1.10

[Kristian Rosenvold]

Thanks for lots of great comments ! Just a few comments about some of the items;

Regarding the *Supplier interfaces, the basic idea is that once
commons-compress reaches jdk 1.8 language level (somewhere in the late
2030's :-) some of such interfaces may be modified to extend
java.util.function.Supplier. And if the supplier throws an exception
it'll be well defined on the interface with clear semantics. I somehow
think these interfaces serve to define the contract a little better
than just a straight callable throwing Exception. It seems  like a
decent way to retromount some jdk8 idioms into jdk[567] compatible
libraries. I'm not really married to this solution, but I think it's
nicer than callable.

ZipArchiveEntryRequest is created for one specific purpose:
ZipArchiveEntry is created on a different thread that has no clear
happens-before relationship to the compressor thread, which means we
cannot really access any fields in that object unless we make them all
volatile. For a long time I figured I could get away without
ZipArchiveEntryRequest but I decided that the threading model would be
too hair-splitting and way too subtle for my liking; I prefer code
that does not require black-belt knowledge in memory model semantics.

I'll look at the specific code stuff for all the parallel code in the weekend.

Kristian


2015-01-23 11:52 GMT+01:00 Emmanuel Bourg ebo...@apache.org:
 Le 22/01/2015 17:30, Stefan Bodewig a écrit :

 Please have a look and identify stuff that looks as if I'd have to
 reroll a new RC should it come to a vote with the current code base.

 I reviewed the API changes, here are my comments:

 - PasswordRequiredException: the exception is in the sevenz package, do
 we want to move it elsewhere so it can be used later for other formats
 like zip (if that makes sense).

 - there are some missing @since tags on the new classes
 (ScatterGatherBackingStoreSupplier, ParallelScatterZipCreator,
 InputStreamSupplier, ZipArchiveEntryRequest, ZipArchiveEntryPredicate)

 - InputStreamSupplier could have been replaced with
 SupplierInputStream if we were using Java 8. But with the current JDK
 I wonder if we could use CallableInputStream instead to spare an
 interface.

 - If we had a kind of DeferredInputStream (not yet in commons-io sadly)
 the API could be slightly simpler. ZipArchiveEntryRequest and
 InputStreamSupplier could go away. DeferredInputStream would open an
 underlying stream only when a read() method is called.

 - ParallelScatterZipCreator has two public methods with a
 CallableObject in the signature, but it's not clear what this Object
 actually is.

 - Is ParallelScatterZipCreator.getStatisticsMessage() intended to remain
 in the final API or was it just there for benchmarking the
 implementation during the development? If it is meant to stay maybe a
 proper ScatterStatistics class would be cleaner.

 - ParallelScatterZipCreator.createCallable: the message of the
 IllegalArgumentException could mention the name of the entry involved.

 - The javadoc of the default ParallelScatterZipCreator constructor could
 explain how the thread pool is sized by default.

 - Could ScatterGatherBackingStoreSupplier be avoided? The public
 ParallelScatterZipCreator constructor that uses it could accept a
 ScatterGatherBackingStore instead, we would just have to ensure that the
 backing store doesn't open resources until it's used.

 - ScatterGatherBackingStore, FileBasedScatterGatherBackingStore and
 ScatterGatherBackingStoreSupplier are in the zip package but have
 nothing specific to the zip format. Should we move them elsewhere so
 they can be used later to implement parallel compression for other formats?

 - BitInputStream: why not using a long cache instead of an int, like
 BitStream before the refactoring? It might be interesting to do some
 benchmarks and see if it make a difference.

 - I think an example demonstrating the parallel zip creation would be a
 nice addition to the site.

 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: [compress] ConcurrentJarCreator

[Kristian Rosenvold]

Yup I'm done, added a small blurb in changes.xml in r1653282.

Btw it still seems like my JIRA karma is a bit weak ?

Kristian


2015-01-20 16:00 GMT+01:00 Stefan Bodewig bode...@apache.org:
 On 2015-01-12, Kristian Rosenvold wrote:

 We had somewhat of a discussion regarding this class on the maven dev
 list over the weekend, some people wanted this code inside
 commons-compress:

 Code is here: 
 https://github.com/krosenvold/plexus-archiver/blob/2.x/src/main/java/org/codehaus/plexus/archiver/zip/ConcurrentJarCreator.java

 I have been thinking a little about this, and my personal preference
 is maybe it would be better for a subsequent release;

 Agreed.

 Do you consider your work in parallel jar creation done for the scope
 of Compress 1.10?  If so, could you please add a blurb in changes.xml?

 I'd like to prepare a first RC of 1.10 this week unless anything is
 still missing.

 Cheers

 Stefan

 -
 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] Too much traffic on the dev ML

[Kristian Rosenvold]

I'd say the problem is probably that you have too little mailing list
traffic incoming. Subscribe to a few more and you /will/ have to start
making inbox rules :)

Kristian (Who had the dubious honor of receiving more email than the
rest of my company altogether last year - 20 people)

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

[compress] ConcurrentJarCreator

[Kristian Rosenvold]

We had somewhat of a discussion regarding this class on the maven dev
list over the weekend, some people wanted this code inside
commons-compress:

Code is here: 
https://github.com/krosenvold/plexus-archiver/blob/2.x/src/main/java/org/codehaus/plexus/archiver/zip/ConcurrentJarCreator.java

I have been thinking a little about this, and my personal preference
is maybe it would be better for a subsequent release; I think it
probably belongs in c-c. But I also think the exact api of this class
is still a bit immature, and it will probably evolve a fair bit more
as I take full consequence of the new api inside maven code. I'm sure
ant code would have the same challenges.

We could of course add it with a huge warning about unstable api etc.
the problem right now is that the code in c-c is more like a
low-level toolbox. The knowledge of how to create a final well-formed
jar file is inside ConcurrentJarCreator.


Kristian

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

Re: [compress] Finished with my changes

[Kristian Rosenvold]

2015-01-10 15:29 GMT+01:00 Stefan Bodewig bode...@apache.org:
 what about the (unrelated) COMPRESS-290?
I'll see what I can do. Should be simple compared to the other stuff
I've been dealing with :)

 and I'll just be running through all the maven test cases tonight.
 Unless bugs pop up I will not be making any further significant
 changes.

They all ran without a glitch based on current head of trunk.

 There are a few findbugs issues in the new zip classes.
I'll take a sweep at that :)

  Test coverage
 of the zip package is better, complexity lower than it has been in 1.9.

W00t? Did *I* manage to /reduce/ complexity ? Must be someone else :)

Kristian

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

[compress] Finished with my changes

[Kristian Rosenvold]

I am finished with all my itches for the next version of c-compress
and I'll just be running through all the maven test cases tonight.
Unless bugs pop up I will not be making any further significant
changes.

I see Stefan has already been doing minor adjustments to some of my
changes. If there's any other documentation I need to update, I'd be
really happy to know.

I'll be closing the jira issues when I'm fully satisfied on my end.

Kristian

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

Re: Wiki Accounts

[Kristian Rosenvold]

I just created KristianRosenvold account on the wiki.

Kristian

2015-01-06 20:46 GMT+01:00 sebb seb...@gmail.com:
 On 6 January 2015 at 19:19, Stefan Bodewig bode...@apache.org wrote:
 Hi

 Luc and Kristian have asked to be added as contributors to the Wiki.  I
 seem to be able to grant that, but need your wiki names in order to do
 so.

 I've done Luc.

 I'm not able to grant Kristian JIRA karma.

 Stefan

 -
 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: [VOTE][LAZY] Migrate Apache Commons Lang to git

[Kristian Rosenvold]

It would appear I do not have access to the commons wiki. If someone
could grant me wiki privs (and Jira at the same time), I can do some
basics for the git wiki page.


Kristian



2015-01-06 18:01 GMT+01:00 sebb seb...@gmail.com:
 -1

 When the first components moved to Git, the agreement was that these
 would be used to iron out any problems and create some documentation
 to enable developers who know SVN to migrate to Git.

 AFAICT there is no such documentation.

 It does not have to be extensive, just some details of commonly used
 SVN commands and their Git equivalents.

 For example:

 svn co, ci, status, diff, revert
 How to create a tag

 Also what changes are needed to the pom.

 This would probably be best done as a Wiki page, at least initially.



 On 3 January 2015 at 12:28, Benedikt Ritter brit...@apache.org wrote:
 Hi all,

 since we made first (good?) experiences with Commons Math using git as
 primary VCS, I'd like to call a vote to migrate Commons Lang to git.

 This vote by lazy consensus will close no sooner than 72 hours from now,
 i.e. after 2014/01/06 13:30 CET.

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


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

Re: [compress] zip64 writing seems to be broken

[Kristian Rosenvold]

2015-01-05 15:12 GMT+01:00 sebb seb...@gmail.com:
 On 5 January 2015 at 13:43, Stefan Bodewig bode...@apache.org wrote:
 On 2015-01-04, Kristian Rosenvold wrote:

 Most surprising to me is that it seems like the overhead of lots of
 small calls to RandomAccessFile.write seems to be a lot costlier than
 I thought it would be. It seems like consolidating to a larger byte
 array before calling write is a *lot* faster.

 This surprises me as well.

 Could be due to need to lock data in memory in native code.
 This usually means data has to be copied to a safe buffer.
 A single large copy will be faster than lots of small ones.

All of this disappears into native code pretty quickly so there might
be OS-specific badness happening on OSX for all I know. I'll check on
linux to see if there's a difference. But one thing is quite clear; if
I do 1000 writes of 100 bytes each (for a grand total of 100K data)  I
can probably /copy/ the data at least 10 times in memory to make up
for the difference in speed.

Kristian

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

Re: [compress] zip64 writing seems to be broken

[Kristian Rosenvold]

Not entirely unsurprisingly this broken in r1648585. I'll try to
understand it tonight

Kristia


2015-01-04 11:37 GMT+01:00 Stefan Bodewig bode...@apache.org:
 On 2015-01-04, Stefan Bodewig wrote:

 I'll try to reproduce this as a unit test for compress later today,

 svn revision 1649312 - run via

 $ mvn test -Dtest=Zip64SupportIT#writeAndRead5GBOfZerosUsingZipFile

 I'll leave my box alone to run the whole suite of ZIP64 ITs (i.e. enable
 the run-zipit profile) and report back later.

 Stefan

 -
 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: [compress] Importance of retaining exact compatibility for ZipArchiveOutputStream ?

[Kristian Rosenvold]

All fixed :)

I also gave up on the ParallelScatterZipCreator#createDeferred and
followed your suggestion.

Kristian


2015-01-02 16:17 GMT+01:00 Stefan Bodewig bode...@apache.org:
 Re backwards compatibility: ZipArchiveOutputStream's deflate method has
 been protected and now has gone.

 On 2014-12-31, Kristian Rosenvold wrote:

 On a related note, I just added the *last* substantial change I intend
 to do. I will do a tweak or two, and I'm sure that last class will
 trigger a truckload of comments, even just the name of the class:)

 I'm notoriously bad at names, so I won't try to color that bikeshed.

 I'll comment on the commit itself.

 Things on my todolist for c-compress:
 A) Make a way to remove tempfiles written by
 ScatterGatherBackingStore.

 +1

 Could you please also add a few sentences to
 http://commons.apache.org/proper/commons-compress/zip.html?

 Thanks!

 Stefan

 -
 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: [compress] Importance of retaining exact compatibility for ZipArchiveOutputStream ?

[Kristian Rosenvold]

2014-12-31 11:50 GMT+01:00 Stefan Bodewig bode...@apache.org:
 On 2014-12-30, Kristian Rosenvold wrote:
 The whole ZipArchiveOutputStream class reminds me of a few of the
 3000+ LOC java classes I refactored in maven core; sometimes the only
 acceptable solution is to extract *all* the logic into other classes
 and just make the old class keep instantiate all the fields and pass
 them on to the underlying new classes with cleaner
 responsibilities. I'm not really saying this should be done, but the
 class has that distinct feeling :)

 Well, when I started it more than thirteen years ago (had to look that
 up :-) it was only ~600 lines and then it grew from that.

Tell me about it. I get serious itches related to such classes :) But
not right now. Must n-o-t shave more yak.


 I'm not trying to defend anything, the class has outgrown its initial
 scope by far and backwards compatibility constraints have made it more
 or less impossible to refactor it properly.  This is one reason why I
 started the compress antlib as the same was true for Ant's zip task
 family.  Some day I'll find time to revive the currently dormant
 compress 2.0 effort ...

I am really not sure big breaks in compatibility are ever worth it. So
that means we just have to be even more clever :)

On a related note, I just added the *last* substantial change I intend
to do. I will do a tweak or two, and I'm sure that last class will
trigger a truckload of comments, even just the name of the class:)

The remaining stuff in
https://github.com/krosenvold/commons-compress/tree/trunk will now go
to plexus. Take a look at ConcurrentJarCreator in my git repo for a
full-scale sample of how to make a zip file.

Things on my todolist for c-compress:
A) Make a way to remove tempfiles written by
ScatterGatherBackingStore. I suspect this will involve renaming
existing close method to something like reverse and making close
actually close (and delete) everything.
B) Optimize LFH generation. I want this in the concurrent scatter
part. The problem with this is that to do this I will need to make a
thread-safe ZipArchiveEntry implementation. Which I have been trying
to avoid. But there's no way around that.

Kristian

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

Re: [compress] Importance of retaining exact compatibility for ZipArchiveOutputStream ?

[Kristian Rosenvold]

2014-12-29 15:05 GMT+01:00 Stefan Bodewig bode...@apache.org:
 On 2014-12-29, Kristian Rosenvold wrote:

 The refactoring os ZipArchiveOutputStream to use StreamCompressor is now 
 done in
 the branch https://github.com/krosenvold/commons-compress

 Some code comments:

 * the fields writtenToOutputStream, sourcePayloadLength and actualCrc in
   StreamCompressor can probably be made private
 * inside the streams we usually write to the underlying stream first and
   update the count later - so the count is never bigger than what has
   been written if the write throws an exception.  I don't think this
   also applied to StreamCompressor's writeCounted but may be nice for
   consistency.
 * ZipArchiveOutputStream's Deflater has been protected and is now
   removed.  We'll need to discuss whether we all can accept the
   potentially breaking change.
I fixed all comments and reinstated the protected Deflater.

 As refactorings come it doesn't feel too good (extracting all the
 methods to create zip headers to a different class would probably be a
 refactoring with a lot better *feeling* to it). This may be due to
 the overall largeness of the file in question, it may also be because
 of the leaks between ZipArchiveOutputStream (fields raf  out) and
 StreamCompressor.

 You could probably remove the out field if you added a flush method to
 the stream compressor.  But the raf field remains for rewriting sizes in
 seekable output - I don't see how this could be moved to
 StreamCompressor without feeling strange.

I think the only way to make this good is to avoid putting all the
seek stuff into the streamcompressor; that's what I did. The whole
ZipArchiveOutputStream class reminds me of a few of the 3000+ LOC java
classes I refactored in maven core; sometimes the only acceptable
solution is to extract *all* the logic into other classes and just
make the old class keep instantiate all the fields and pass them on
to the underlying new classes with cleaner responsibilities. I'm not
really saying this should be done, but the class has that distinct
feeling :)

I took Gary's cheap solution to the StreamCompressor subclass
issue; I just made the whole streamcompressor package private and not
a part of any public api. Given that it's not really meant to be an
extension point I think this is adequate. Alternately I would actually
consider going back to the old if statement that used to be there
before I introduced all the OO political correctness.

Kristian

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

Re: [compress] Importance of retaining exact compatibility for ZipArchiveOutputStream ?

[Kristian Rosenvold]

2014-12-28 11:35 GMT+01:00 Stefan Bodewig bode...@apache.org:
 On 2014-12-26, Kristian Rosenvold wrote:
 A) Think about manifest handling in genreal

 This applies to plexus since CC isn't doing any manifest handling at all
 right now.
Yes, I'm thinking along the lines of just making it easy for the
client to do this task. I'll try to keep the manifest-specific stuff
out of CC.

 D) Look at performance in the gather phase. It's too slow right now,
 even with my last commit on trunk. Consider moving the creation of the
 LFH to the multithreaded parts and actually copy parts to the central
 directory upon merging. Ideally, the gather phase should be just IO.
 Maybe make the creation of the central directory a Deferred stream
 too, preferably of the offloading type.

 As long as you only write to the central directory stream after you've
 completely written the entry (otherwise you may not know the sizes
 depending on the method and whether the backing store is seekable) this
 should be doable.

The nice thing about using ScatterZipOutputStream first is that we
know *everything* about sizes and crcs before we start writing the zip
file. So the only thing we really need to know for the central
directory is the offset, which is also known up-front as long as
scatter is fully complete before gather. So at some point I'll also be
looking at single-pass zip writing in ZipArchiveOutputStream (when
using raw methods), but that's on the nice to have list.


 May I ask sneaking in prefer using delegation over inheritance where
 possible? ;-)

OMG; I seem to have gone full circle on this. I have been deeply in
the prefer delegation camp for the last 15 years or so. For the last
year or so I have been exposed to inheritance-based extensions in
@dayjob, and it's rubbing off on me

Kristian

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

[compress] Refactoring to interfaces in Scatter* logic

[Kristian Rosenvold]

Stefan, I looked at your changes in the github repo
https://github.com/bodewig/commons-compress/commits/scatter-backing-store

I think they look great. Please commit them :)

Kristian

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

Re: [compress] Importance of retaining exact compatibility for ZipArchiveOutputStream ?

[Kristian Rosenvold]

The refactoring os ZipArchiveOutputStream to use StreamCompressor is now done in
the branch https://github.com/krosenvold/commons-compress

As refactorings come it doesn't feel too good (extracting all the
methods to create zip headers to a different class would probably be a
refactoring with a lot better *feeling* to it). This may be due to
the overall largeness of the file in question, it may also be because
of the leaks between ZipArchiveOutputStream (fields raf  out) and
StreamCompressor.

It removes the duplication and is probably better since it clearly
decouples one aspect of the algorithm from the rest. I just wish I
could get it even better  Feedback welcome :)

Kristian



2014-12-26 18:54 GMT+01:00 Stefan Bodewig bode...@apache.org:
 On 2014-12-23, Stefan Bodewig wrote:

 Your commit message calls out writeOut as a particilar problem.
 Fortunately this is one is final, so we don't have to retain the effect
 of subclasses overriding it.  Wouldn't it be possible to have writeOut
 call the StreamCompressor's writeOut method so it still worked as
 before?

 I see you've already started to implement that in your github fork. :-)

 [As an aside I'd prefer the StreamCompressor being passed into the
 stream so we don't need subclasses just to replace the compressor.]

 At least for the ScatterZipOutputStream I've started to experiment a
 little:
 https://github.com/bodewig/commons-compress/compare/scatter-backing-store

 As for

 One problem of the zip package is that it doesn't support all the
 other compression methods possible for ZIPs, this might be a possible
 extension point.

 I'd like to see where you are going to take the compressor before I try
 to dive in.  Do I need to look at your plexus-archiver fork?

 Stefan

 -
 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: [compress] Importance of retaining exact compatibility for ZipArchiveOutputStream ?

[Kristian Rosenvold]

Yup; I'm taking care of the duplication in trunk on my github fork.
The other interesting branch to look at is the somewhat stale
concurrentSupport branch and in particular the class
ConcurrentZipCreator. This is my primary goal, I just went off on a
round of yak-shaving first. I seem to have finished with the yaks now,
so
I aim to rebase this branch to trunk soon.

I suppose I will be committing the ConcurrentZipCreator to
c-compress. Originally I had this in plexus-archiver, but I moved it
over once the use case was sufficiently well understood. So right now
I have no code in plexus-archiver, other than a branch or two with
early versions of ConcurrentZipCreator in it.

Right now the problem of multiple algorithms is not my itch; I have
enough other itches right now.

My todo list right now look like this:
A) Think about manifest handling in genreal
B) Investigate manifest merging in ConcurrentZipCreator. ATM I'm just
thinking of exposing all the added manifests as a collection and
leaving this to the client to merge stuff when multiple manfests are
present.
C) Decide on the ultimate thread-safety issues in the client front-end
(ConcurrentZipCreator). I'm walking the line right now (quite a risky
model), and I'd like to make it clearer.
D) Look at performance in the gather phase. It's too slow right now,
even with my last commit on trunk. Consider moving the creation of the
LFH to the multithreaded parts and actually copy parts to the central
directory upon merging. Ideally, the gather phase should be just IO.
Maybe make the creation of the central directory a Deferred stream
too, preferably of the offloading type.

I suppose that about sums it up. When these things are done I'm ready :)

Kristian



2014-12-26 18:54 GMT+01:00 Stefan Bodewig bode...@apache.org:
 On 2014-12-23, Stefan Bodewig wrote:

 Your commit message calls out writeOut as a particilar problem.
 Fortunately this is one is final, so we don't have to retain the effect
 of subclasses overriding it.  Wouldn't it be possible to have writeOut
 call the StreamCompressor's writeOut method so it still worked as
 before?

 I see you've already started to implement that in your github fork. :-)

 [As an aside I'd prefer the StreamCompressor being passed into the
 stream so we don't need subclasses just to replace the compressor.]

 At least for the ScatterZipOutputStream I've started to experiment a
 little:
 https://github.com/bodewig/commons-compress/compare/scatter-backing-store

 As for

 One problem of the zip package is that it doesn't support all the
 other compression methods possible for ZIPs, this might be a possible
 extension point.

 I'd like to see where you are going to take the compressor before I try
 to dive in.  Do I need to look at your plexus-archiver fork?

 Stefan

 -
 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: r1647329 - in /commons/proper/compress/trunk/src: main/java/org/apache/commons/compress/archivers/zip/ test/java/org/apache/commons/compress/archivers/ test/java/org/apache/commons/com

[Kristian Rosenvold]

It depends :)

All the commits I did so far represent distinct pieces of
functionality that someone could choose to use by itself, so if
c-compress was released tomorrow they'd be usable. That being said,
I'm still polishing the last high-level class that provides the
consumer-friendlier stuff to create a zip or a jar file. Even when I
do that, some of the underlying stuff will be visible.

ScatterZipOutputStream is client extensible to provide different kinds
of backing store for the intermediate output. I might be able to hide
the StreamCompressor is part of the extensible type hierarchy for
ScatterZipOutputStream; I'll take a look.

As you may have seen, there is one subclass
org.apache.commons.compress.archivers.zip.ScatterZipOutputStream.FileScatterOutputStream
that is implemented right now, which backs it straight to file. It is
possible for clients to make their own backing implementations of the
ScatterZipOutputStream. In my git repo I have 2 other implementations,
one using the commons-io DeferredOutputStream and another one using a
custom OffloadingDeferredOutputstream, that basically offloads to
disk after N bytes but retains the stuff already written to memory.
(Deferred flushes *everything* to disk once it switches to
disk-based). Adding these two last implementations to commons-compress
would imply adding at least an optional dependency to commons-io, and
I have been deferring that question :) I can think of at least a 4th
implementation, which would use off-heap memory for storing stuff.

Kristian


2014-12-23 12:02 GMT+01:00 Emmanuel Bourg ebo...@apache.org:
 Le 22/12/2014 16:24, krosenv...@apache.org a écrit :
 Author: krosenvold
 Date: Mon Dec 22 15:24:02 2014
 New Revision: 1647329

 URL: http://svn.apache.org/r1647329
 Log:
 COMPRESS-296 Parallel compression. Added StreamCompressor and 
 ScatterZipOutputStream.

 StreamCompressor is an extract of the deflation algorithm from 
 ZipArchiveOutputStream, which unfortunately
 was too conflated with writing a file in a particular structure. Using the 
 actual zip file format as an
 intermediate format for scatter-streams turned out to be fairly inefficient. 
 ScatterZipOuputStream
 is 2-3x faster than using a zip file as intermediate format.

 It would be possibly to refactor ZipArchiveOutputStream to use 
 StreamCompressor, but there would
 be a slight break in backward compatibility regarding the protected writeOut 
 method, which
 is moved to the streamCompressor class.

 Thank you Kristian. Is it possible to make the new classes package
 private or do they have to be part of the public API?

 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: [io] Make org.apache.commons.io.output.ByteArrayOutputStream resversible ?

[Kristian Rosenvold]

doh. That's what I get for looking at released versions instead of
reading code at trunk like real grownups do.

Thanks,


Kristian


2014-12-23 11:08 GMT+01:00 sebb seb...@gmail.com:
 On 23 December 2014 at 07:55, Kristian Rosenvold krosenv...@apache.org 
 wrote:
 I'd like to make a public (synchronized) version of the
 toBufferedInputStream method in this class, which would allow
 zero-copy turnaround of the outputstream to an input-stream; I am a
 bit puzzled why this hasn't been done yet.

 Huh?

 What's wrong with the existing method:

 InputStream org.apache.commons.io.output.ByteArrayOutputStream.toInputStream()

 Ok ?

 Kristian

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


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


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

Re: svn commit: r1647329 - in /commons/proper/compress/trunk/src: main/java/org/apache/commons/compress/archivers/zip/ test/java/org/apache/commons/compress/archivers/ test/java/org/apache/commons/com

[Kristian Rosenvold]

Thanks for the comments, fixed in r1647582.

Is there such a thing as a commons IntelliJ code style file ?

Kristian


2014-12-23 11:46 GMT+01:00 sebb seb...@gmail.com:
 On 22 December 2014 at 15:24,  krosenv...@apache.org wrote:
 Author: krosenvold
 Date: Mon Dec 22 15:24:02 2014
 New Revision: 1647329

 URL: http://svn.apache.org/r1647329
 Log:
 COMPRESS-296 Parallel compression. Added StreamCompressor and 
 ScatterZipOutputStream.

 StreamCompressor is an extract of the deflation algorithm from 
 ZipArchiveOutputStream, which unfortunately
 was too conflated with writing a file in a particular structure. Using the 
 actual zip file format as an
 intermediate format for scatter-streams turned out to be fairly inefficient. 
 ScatterZipOuputStream
 is 2-3x faster than using a zip file as intermediate format.

 It would be possibly to refactor ZipArchiveOutputStream to use 
 StreamCompressor, but there would
 be a slight break in backward compatibility regarding the protected writeOut 
 method, which
 is moved to the streamCompressor class.

 Added:
 
 commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ScatterZipOutputStream.java
 
 commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/StreamCompressor.java
 
 commons/proper/compress/trunk/src/test/java/org/apache/commons/compress/archivers/zip/ScatterZipOutputStreamTest.java
 
 commons/proper/compress/trunk/src/test/java/org/apache/commons/compress/archivers/zip/StreamCompressorTest.java
 Modified:
 
 commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipArchiveOutputStream.java
 
 commons/proper/compress/trunk/src/test/java/org/apache/commons/compress/archivers/ZipTestCase.java

 Added: 
 commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ScatterZipOutputStream.java
 URL: 
 http://svn.apache.org/viewvc/commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ScatterZipOutputStream.java?rev=1647329view=auto
 ==
 --- 
 commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ScatterZipOutputStream.java
  (added)
 +++ 
 commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ScatterZipOutputStream.java
  Mon Dec 22 15:24:02 2014
 @@ -0,0 +1,174 @@
 +/*
 + *  Licensed to the Apache Software Foundation (ASF) under one or more
 + *  contributor license agreements.  See the NOTICE file distributed with
 + *  this work for additional information regarding copyright ownership.
 + *  The ASF licenses this file to You under the Apache License, Version 2.0
 + *  (the License); you may not use this file except in compliance with
 + *  the License.  You may obtain a copy of the License at
 + *
 + *  http://www.apache.org/licenses/LICENSE-2.0
 + *
 + *  Unless required by applicable law or agreed to in writing, software
 + *  distributed under the License is distributed on an AS IS BASIS,
 + *  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 + *  See the License for the specific language governing permissions and
 + *  limitations under the License.
 + *
 + */
 +package org.apache.commons.compress.archivers.zip;
 +
 +
 +import org.apache.commons.compress.utils.BoundedInputStream;
 +
 +import java.io.*;
 +import java.util.*;

 Don't use wildcard imports (except possibly static ones)

 +import java.util.concurrent.ConcurrentLinkedQueue;
 +import java.util.zip.Deflater;
 +
 +/**
 + * A zip output stream that is optimized for multi-threaded scatter/gather 
 construction of zip files.
 + * p/
 + * The internal data format of the entries used by this class are entirely 
 private to this class
 + * and are not part of any public api whatsoever.
 + * p/
 + * It is possible to extend this class to support different kinds of 
 backing storage, the default
 + * implementation only supports file-based backing.
 + * p/
 + * Thread safety: This class supports multiple threads. But the writeTo 
 method must be called
 + * by the thread that originally created the ZipArchiveEntry.
 + *
 + * @since 1.10
 + */
 +public abstract class ScatterZipOutputStream  {
 +private final QueueCompressedEntry items = new 
 ConcurrentLinkedQueueCompressedEntry();
 +
 +private static class CompressedEntry {
 +final ZipArchiveEntry entry;
 +final long crc;
 +final long compressedSize;
 +final int method;
 +final long size;
 +
 +public CompressedEntry(ZipArchiveEntry entry, long crc, long 
 compressedSize, int method, long size) {
 +this.entry = entry;
 +this.crc = crc;
 +this.compressedSize = compressedSize;
 +this.method = method;
 +this.size = size;
 +}
 +
 +public ZipArchiveEntry transferToArchiveEntry(){
 +

Re: svn commit: r1646531 - in /commons/proper/compress/trunk: ./ src/main/java/org/apache/commons/compress/archivers/zip/ src/test/java/org/apache/commons/compress/ src/test/java/org/apache/commons/co

[Kristian Rosenvold]

I'll put taking a look at addRawArchiveEntry  with ZipEntry on my todo
list. I have quite a few threads converging into the last class
already; but everything should be done in a few days now.

copyRawEntries could definitely be somewhere else. Originally I
implemented it on ZipArchiveOutputStream, but it's really not that
much better :)

Kristian


2014-12-23 18:43 GMT+01:00 Stefan Bodewig bode...@apache.org:
 On 2014-12-18, krosenv...@apache.org wrote:

public void addRawArchiveEntry(ZipArchiveEntry entry, InputStream 
 rawStream)

 Technically entry could be a java.util.zip.ZipEntry, I'm not sure this
 would open up new opportunities, though.

/**
 * Transfer selected entries from this zipfile to a given 
 #ZipArchiveOutputStream.
 * Compression and all other attributes will be as in this file.
 * This method transfers entries based on the central directory of the 
 zip file.
 *
 * @param target The zipArchiveOutputStream to write the entries to
 * @param predicate A predicate that selects which entries to write
 */
public void copyRawEntries(ZipArchiveOutputStream target, 
 ZipArchiveEntryPredicate predicate)
throws IOException {

 I'm not entirely sure this should be an instance method of ZipFile, it
 looks more like a utility method that could live outside of the class as
 it doesn't need any of the non-public parts of it.

 Then again ZipUtil is a bag of pretty unrelated methods so it doesn't
 sound like a happy place for it either.

 Stefan

 -
 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

[compress] Importance of retaining exact compatibility for ZipArchiveOutputStream ?

[Kristian Rosenvold]

There are quite a few extension points in this class that make
changing it really hard.

I just committed  r1647329 which basically duplicates some code from
this class into another class. As much as I hate duplication, I wasn't
able to achieve what I wanted to without A) breaking some extension
capability of the existing class or B) duplicating the code.

We are not talking about the bread and butter usage of the class
here but rather intricate extensions I'm unsure of how many people
use. If it was up to me I'd break compatibility slightly an make a
JIRA that explains how to migrate forwards and hence move the class to
a somewhat better state. As things are right now I retained
compatibility by not changing the class itself.

WDYT ?

Kristian

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

[io] Make org.apache.commons.io.output.ByteArrayOutputStream resversible ?

[Kristian Rosenvold]

I'd like to make a public (synchronized) version of the
toBufferedInputStream method in this class, which would allow
zero-copy turnaround of the outputstream to an input-stream; I am a
bit puzzled why this hasn't been done yet.

Ok ?

Kristian

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

Re: [compress] Changes to allow multithreaded creation of zip files

[Kristian Rosenvold]

+1 for moving to git btw :)

Kristian

2014-12-15 11:38 GMT+01:00 Emmanuel Bourg ebo...@apache.org:
 Le 15/12/2014 11:36, Stefan Bodewig a écrit :

 [as an aside, maybe we should think about moving Compress to git]

 +1

 Emmanuel


 -
 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: [compress] Changes to allow multithreaded creation of zip files

[Kristian Rosenvold]

I just landed two commits for COMMONS-295 and COMMONS-296, which is
the groundwork for proper parallel support. The icing on the cake (the
high-level api with nThreads configuration and single point of
entry) is still work-in-progress and can be seen at
https://github.com/krosenvold/commons-compress/tree/concurrentSupport

It's still early days for the high level service; it needs to do
lots of funky stuff like balance large files first and use work
stealing towards the end. Currently I can easily make this use 850%
CPU on my 6 core cpu.

The cool stuff is still in github, but it's a lot easier for
anyone to build and play around with now.

Kristian


2014-12-18 9:29 GMT+01:00 Kristian Rosenvold krosenv...@apache.org:
 +1 for moving to git btw :)

 Kristian

 2014-12-15 11:38 GMT+01:00 Emmanuel Bourg ebo...@apache.org:
 Le 15/12/2014 11:36, Stefan Bodewig a écrit :

 [as an aside, maybe we should think about moving Compress to git]

 +1

 Emmanuel


 -
 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: [compress] Changes to allow multithreaded creation of zip files

[Kristian Rosenvold]

Amazing digging; thanks a lot. At least for maven's code, introducing
the concept of a root stream that will be the start of the physical
zip stream can simplify things quite a lot.

Kristian


2014-12-16 6:48 GMT+01:00 Stefan Bodewig bode...@apache.org:
 On 2014-12-15, Kristian Rosenvold wrote:

 There is also the issue of determining if the MANIFEST.MF file really
 needs to be the first file in the jar, which puts an interesting
 constraint on the parallelism.

 I've found this for Ant which caused us to implement that logic (in 2001):

 https://issues.apache.org/bugzilla/show_bug.cgi?id=3287

 It seems this is an implementation detail of JarInputStream that Ant and
 Maven have learned to cope with.  And it still seems to be true:

 http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/9ade71a206f9/src/java.base/share/classes/java/util/jar/JarInputStream.java#l79

 I wouldn't be suprised if other tools relied on it as well.

 Stefan

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

Re: [compress] Changes to allow multithreaded creation of zip files

[Kristian Rosenvold]

As far as I understand there will be no thread pools coming into
commons-compress, this has to be done by the caller. The caller will
basically in some shape or another keep at ThreadLocal
ZipArchiveOutputStream that will receive entries for each thread.
When everyone is finished they will be merged (or maybe just appended
to the one ZipArchiveOutputStream that is master and already
pointing to the final file).

All c-compress needs to do is have support for transferring already
compressed content from one outputstream to another, probably by
reversing the outputstream back to an inputstream and appending all
the entries to a different outputstream through regular iteration.

There is also the issue of determining if the MANIFEST.MF file really
needs to be the first file in the jar, which puts an interesting
constraint on the parallelism. I have been unable to understand if the
jar spec actually requires this or if it's just stuff from the old
days.

In maven we use plexus-archiver, which allows higher-level creation of
zip archives (add a bunch of source specifications to archiver and
say execute and you get your zip/tar files etc). The executor will
be in plexus-archiver for our code. I've been tweaking this code for
some time now with an eye to parallelize the whole thing; som now I'm
moving for the kill :)

Kristian





2014-12-15 13:06 GMT+01:00 Gary Gregory garydgreg...@gmail.com:
 Sounds cool. Do you plan on allowing  an executor service to be passed in to 
 some APIs?

 Gary

 div Original message /divdivFrom: Kristian Rosenvold 
 krosenv...@apache.org /divdivDate:12/15/2014  02:49  (GMT-05:00) 
 /divdivTo: Commons Developers List dev@commons.apache.org 
 /divdivCc:  /divdivSubject: [compress] Changes to allow multithreaded 
 creation of zip files /divdiv
 /divI just thought I'd let you know I'm working on changes to allow
 multiple threads to output to different ZipArchiveOutputStream
 instances (backed  by commons-io DeferredFileOutputStream or similar)
 and then stitch the results back together as a single Zip file. I'm
 currently just researching the scope of the required changes (which
 seems to be fairly small) and working on test cases. I expect to be
 working with this for a few weeks, my code can be seen at
 https://github.com/krosenvold/commons-compress

 (And I'll be implementing this in maven once it's good).

 Kristian

 -
 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: [DRAFT][ANNOUNCE] Apache Commons grants write access to all ASF committers

[Kristian Rosenvold]

Nice move;

This is actually the way I thought commons worked (when I was a kid)
until I learned that I did not understand how commons worked :)

Kristian




2014-12-15 6:27 GMT+01:00 Matt Benson gudnabr...@gmail.com:
 On Dec 14, 2014 9:04 PM, Gary Gregory garydgreg...@gmail.com wrote:

 Nice feedback all around. Here is a version that includes some of these
 thoughts:
 --

 Dear fellow committers,

 The Apache Commons Team is pleased to announce that write access to the
 Apache Commons Subversion and Git repositories has been granted to all ASF
 committers.

 Apache Commons is an Apache project focused on all aspects of reusable
 Java
 components. As such, the components maintained by the Apache Commons
 project
 may be of interest to a variety of other Apache projects.

 The Apache Commons community would like to invite you to share and
 maintain
 useful code.

 While Apache Commons is a Commit-Then-Review community, we would consider
 it polite and helpful for contributors to announce their intentions and
 plans on the dev mailing list before committing code.


 Have fun,

 The Apache Commons Community.
 --
 Gary


 Sounds good.

 Matt


 On Sun, Dec 14, 2014 at 3:13 PM, Gilles gil...@harfang.homelinux.org
 wrote:
 
  On Sun, 14 Dec 2014 12:57:02 -0700, Phil Steitz wrote:
 
  On 12/14/14 12:49 PM, Gilles wrote:
 
  On Sun, 14 Dec 2014 20:28:37 +0100, Benedikt Ritter wrote:
 
  Hi all,
 
  here is my draft for the announcement to committers@
 
  Regards,
  Benedikt
 
  --
 
  Dear fellow committers,
 
  the Apache Commons Team is pleased to announce that write access
  to the
  Apache Commons SVN and git repositories has been granted to all ASF
  committers.
 
  Apache Commons is an Apache project focused on all aspects of
  reusable Java
  components. As such the components maintained by the Apache
  Commons project
  may be of interest for a variety of other Apache projects.
 
  The Apache Commons community would like to invite you to share
  useful code
  which may be useful for other projects as well.
  Please let us know before you start working on the code, by
  writing a short
  mail to the dev mailing list [1].
 
 
  I'd be more careful (better safe than sorry) and add something like:
 
  [...] before committing code, consensus about the modifications
  should be
  reached on the dev ML.
 
 
  We are CTR so that is not necessary.  We might just want to refer to
  and update [1].
 
 
  IMHO, it is more efficient to discuss first (with the assumption that
  no objection amounts to green light).
 
   The upshot there is that before starting to commit
  to a component, it is polite to announce intention to start working
  on it and let people know what you have in mind.
 
 
  In the same vein, it is more polite to ask first whether there is an
  objection).
  It is also nicer, for all parties, to not have to veto a commit.
 
 
  Gilles
 
 
 
   Phil
 
  [1] http://wiki.apache.org/commons/CommonsEtiquette
 
 
 
  Thanks,
  Gilles
 
 
  Benedikt Ritter,
  on behalf of the Apache Commons community
 
  [1] http://commons.apache.org/mail-lists.html
 
 
 
 
  -
  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
 
 

 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second Edition
 http://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 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