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

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

[io] commons-io git repository ready

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

Re: [CSV] Git Migration

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

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

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

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

+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

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

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(); >

Re: Reformatting commons-io to single code style ?

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

Reformatting commons-io to single code style ?

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

Re: [VOTE] Move Apache Commons Primitives to dormant

+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

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

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

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

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?

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

Re: [ANN] Apache Commons IO 2.5 Released

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.

Re: [ANN] Apache Commons IO 2.5 Released

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

Re: [io] 2.5 vote...

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 |

Re: [VOTE] Release commons-io RC2

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 w

Re: [VOTE] Release commons-io RC2

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

[VOTE] Release commons-io RC2

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:

Re: [io] Java 7

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

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

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

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

uot;. 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 q

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

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) >>

[VOTE] Release commons-io 2.5 based on RC1

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:

commons-io 2.5 RC1 tomorrow

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:

Re: SafeObjectInputStream in Commons?

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

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

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

Re: [validator] Inconsistent behavior in UrlValidator

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

Re: [validator] Inconsistent behavior in UrlValidator

n 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 >> >> Krist

Version number for next commons-io

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

Re: Version number for next commons-io

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

Re: Version number for next commons-io

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 affec

Missing nexus "stage" permissions....

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

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

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; >> &

Re: [VOTE] Move COMPRESS to git

+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

Re: [VOTE] Release Commons Compress Based on RC3

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

Re: [VOTE] Release Commons Compress Based on RC3

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

Re: commit problem

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

Re: commit problem

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

Re: Wlcome to the Apache Commons PMC

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

Re: [io] xml parser blues :)

) 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

[io] xml parser blues :)

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

Re: [io] xml parser blues :)

/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

[io] Preparing for 2.5 release

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

Re: [io] How picky about backward compatibility ?

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

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

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

Re: [io] How picky about backward compatibility ?

. 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

Re: Jira permissions gone .. ?

: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

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

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 ?

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

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

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

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

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

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

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

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

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

[io] svn commit r1686512

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 ?

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

Jira permissions gone .. ?

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

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

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/

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

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/

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

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/

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

Re: [io] Is commons-io dormant?

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

Re: [io] Is commons-io dormant?

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

Re: [LANG] Add ThreadUtils

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

Re: [VOTE] Release Compress 1.10 Based on RC1

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

Re: [VOTE] Release Compress 1.10 Based on RC1

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:

Re: [VOTE] Release Compress 1.10 Based on RC1

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

Re: [VOTE] Release Compress 1.10 Based on RC1

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

Re: [VOTE] Release Compress 1.10 Based on RC1

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

Re: [compress] Preparations for 1.10

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

Re: [compress] Preparations for 1.10

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

Re: [ALL] JIRA permissions for 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

Re: [ALL] JIRA permissions for 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

Re: [compress] Preparations for 1.10

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

Re: [compress] ConcurrentJarCreator

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

Re: [ALL] Too much traffic on the dev ML

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)

[compress] ConcurrentJarCreator

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

Re: [compress] Finished with my changes

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

[compress] Finished with my changes

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

Re: Wiki Accounts

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

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

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

Re: [compress] zip64 writing seems to be broken

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

Re: [compress] zip64 writing seems to be broken

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

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

-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

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

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

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

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

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

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

[compress] Refactoring to interfaces in Scatter* logic

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:

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

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

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

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

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

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

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

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

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

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:

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

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

[compress] Importance of retaining exact compatibility for ZipArchiveOutputStream ?

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

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

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

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

+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

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

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

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

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

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

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

Re: [DRAFT][ANNOUNCE] Apache Commons grants write access to all ASF committers

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

  1   2   >