Re: [continuum] BUILD FAILURE: Apache Commons - Commons VFS -

Hi all, Is this a corrupted maven local cache issue? A maven 2 vs 3 issue? Gary On Aug 7, 2013, at 23:21, "Continuum@vmbuild" wrote: > Local Maven 2 Build Definition (Java 1.6) > MIME-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > X-Conti

[continuum] BUILD FAILURE: Apache Commons - Commons VFS -

Local Maven 2 Build Definition (Java 1.6) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Continuum-Build-Host: vmbuild X-Continuum-Project-Id: 129 X-Continuum-Project-Name: Commons VFS Online report : http://vmbuild.apache.org/continuum/bu

Re: [VFS] RAM Provider review and questions

On Wed, Aug 7, 2013 at 10:02 PM, Bernd Eckenfels wrote: > Am 08.08.2013, 03:49 Uhr, schrieb Gary Gregory : > > > https://issues.apache.org/**jira/browse/VFS-483 >> >> to track all of this. See the link for updates and status. >> > > Very cool thanks

Re: [pool] 2.0 factory interfaces WAS: Re: svn commit: r1506685 - in /commons/proper/pool/trunk/src: main/java/org/apache/commons/pool2/ main/java/org/apache/commons/pool2/impl/ test/java/org/apache/

On 8/4/13 9:27 AM, Phil Steitz wrote: > On 8/4/13 7:24 AM, Mark Thomas wrote: >> On 03/08/2013 17:15, Phil Steitz wrote: >>> On 7/30/13 9:16 AM, Phil Steitz wrote: I have started working on this. Should have something to commit at least for GOP in the next day or two. >>> I am stuck on S

[continuum] BUILD FAILURE: Apache Commons - Commons VFS -

Local Maven 2 Build Definition (Java 1.6) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Continuum-Build-Host: vmbuild X-Continuum-Project-Id: 129 X-Continuum-Project-Name: Commons VFS Online report : http://vmbuild.apache.org/continuum/bu

Re: [VFS] RAM Provider review and questions

Am 08.08.2013, 03:49 Uhr, schrieb Gary Gregory : https://issues.apache.org/jira/browse/VFS-483 to track all of this. See the link for updates and status. Very cool thanks, I would also have files some, after discussion where a change makes sense. I filed this one here for the test package;

Re: [VFS] RAM Provider review and questions

I created https://issues.apache.org/jira/browse/VFS-483 to track all of this. See the link for updates and status. Gary On Wed, Aug 7, 2013 at 5:36 PM, Bernd Eckenfels wrote: > Hello, > > I had a look at the VFS2 RAM Provider in 2.0 and have some questions > comments: > > > RamFileData.java >

Re: [Math] Fluent API, inheritance and immutability

On Wed, 7 Aug 2013 18:04:39 -0400, Evan Ward wrote: Hi, As a grateful user of the library, I would prefer the Fluent API and immutability. I have implemented this pattern in some of my own projects and it makes the API very easy to use. Most of the time, when the interface is small, inheritan

Re: [Math] Fluent API, inheritance and immutability

On Wed, 7 Aug 2013 13:39:41 -0700, Ted Dunning wrote: This is often dealt with by using builder classes and not putting all the fluent methods on the objects being constructed. Builders seem fine when no inheritance is involved: all fields are duplicated (and mutable) in the builder, then an i

[Math] Fluent API, inheritance and immutability

Hi, As a grateful user of the library, I would prefer the Fluent API and immutability. I have implemented this pattern in some of my own projects and it makes the API very easy to use. Most of the time, when the interface is small, inheritance isn't really necessary and I just implement the withX

[VFS] RAM Provider review and questions

Hello, I had a look at the VFS2 RAM Provider in 2.0 and have some questions comments: RamFileData.java #52 byte[] buffer - this is the actual content of the file, I would name it that way. Buffer sounds transient #62 Collection - this keeps references to all childer, aka

Re: [Math] Fluent API, inheritance and immutability

This is often dealt with by using builder classes and not putting all the fluent methods on the objects being constructed. The other way to deal with this is to use a covariant return type. For instance, there is no guarantee that Pattern.compile returns any particular class other than that it re

[Math] Fluent API, inheritance and immutability

Hi. It seems that each two of those concepts are at odds with the third one. E.g. you can have a fluent API and immutability, but this then prevents you from defining fluent API methods in a base class because immutability requires creating a new object (but the base class cannot know how to "bu

Re: svn commit: r1511316 - in /commons/proper/compress/trunk/src: main/java/org/apache/commons/compress/archivers/cpio/CpioArchiveInputStream.java test/java/org/apache/commons/compress/archivers/cpio/

Le 07/08/2013 16:41, sebb a écrit : > > -1 > > Surely that will cause API breakage? I don't think so, this is source and binary compatible, unless someone extended the class and overrode the method, which is very unlikely. I wrote a simple test and compiled it with Commons Compress 1.5: Cp

Re: svn commit: r1511326 - in /commons/proper/compress/trunk/src: main/java/org/apache/commons/compress/archivers/dump/ main/java/org/apache/commons/compress/compressors/bzip2/ test/java/org/apache/co

Le 07/08/2013 17:15, Stefan Bodewig a écrit : > I'm not sure whether we have any policy on this, but so far I've tried > to stick with 80 columns max. Maybe that's a sign of me being old > fashioned, don't know :-) 80 columns is quite restrictive with today's wide screens and often cause excessi

Re: svn commit: r1511326 - in /commons/proper/compress/trunk/src: main/java/org/apache/commons/compress/archivers/dump/ main/java/org/apache/commons/compress/compressors/bzip2/ test/java/org/apache/co

On Wed, Aug 7, 2013 at 11:15 AM, Stefan Bodewig wrote: > On 2013-08-07, wrote: > > > -public BZip2CompressorInputStream(final InputStream in, > > - final boolean > decompressConcatenated) > > -throws IOException { > > - > > +public BZip2Co

Re: svn commit: r1511326 - in /commons/proper/compress/trunk/src: main/java/org/apache/commons/compress/archivers/dump/ main/java/org/apache/commons/compress/compressors/bzip2/ test/java/org/apache/co

On 2013-08-07, wrote: > -public BZip2CompressorInputStream(final InputStream in, > - final boolean decompressConcatenated) > -throws IOException { > - > +public BZip2CompressorInputStream(final InputStream in, final boolean > decompressCon

Re: [csv] type name consistency

On Wed, Aug 7, 2013 at 10:39 AM, sebb wrote: > On 7 August 2013 14:15, Gary Gregory wrote: > > On Wed, Aug 7, 2013 at 2:45 AM, Benedikt Ritter > wrote: > > > >> 2013/8/7 Gary Gregory > >> > >> > I think we can be done unless other opinions come in... > >> > > >> > >> What about Quote? Do we wa

Re: svn commit: r1511316 - in /commons/proper/compress/trunk/src: main/java/org/apache/commons/compress/archivers/cpio/CpioArchiveInputStream.java test/java/org/apache/commons/compress/archivers/cpio/

On 2013-08-07, wrote: > Author: ebourg > Date: Wed Aug 7 13:52:00 2013 > New Revision: 1511316 > URL: http://svn.apache.org/r1511316 > Log: > Changed the return type of CpioArchiveInputStream.getNextEntry() to avoid > casting to CpioArchiveEntry please don't. Let's leave that for 2.0. Stefa

Re: svn commit: r1511316 - in /commons/proper/compress/trunk/src: main/java/org/apache/commons/compress/archivers/cpio/CpioArchiveInputStream.java test/java/org/apache/commons/compress/archivers/cpio/

On 7 August 2013 14:52, wrote: > Author: ebourg > Date: Wed Aug 7 13:52:00 2013 > New Revision: 1511316 > > URL: http://svn.apache.org/r1511316 > Log: > Changed the return type of CpioArchiveInputStream.getNextEntry() to avoid > casting to CpioArchiveEntry -1 Surely that will cause API breaka

Re: [csv] final types

I'm still not convinced this is warranted, but I voted -0 On Wednesday, August 7, 2013, sebb wrote: > On 7 August 2013 13:11, James Carman > > > wrote: > > What exactly does it hurt by leaving them non-final? It's not like we > have > > to support folks doing stupid things. One user doing some

Re: [csv] type name consistency

On 7 August 2013 14:15, Gary Gregory wrote: > On Wed, Aug 7, 2013 at 2:45 AM, Benedikt Ritter wrote: > >> 2013/8/7 Gary Gregory >> >> > I think we can be done unless other opinions come in... >> > >> >> What about Quote? Do we want to move it to CSVFormat? Makes sense because >> it is really par

Re: [csv] final types

On 7 August 2013 13:11, James Carman wrote: > What exactly does it hurt by leaving them non-final? It's not like we have > to support folks doing stupid things. One user doing something > silly doesn't impact other users either. I guess I don't understand the > paranoia here. It's not paranoia

Re: [csv] type name consistency

On Wed, Aug 7, 2013 at 2:45 AM, Benedikt Ritter wrote: > 2013/8/7 Gary Gregory > > > I think we can be done unless other opinions come in... > > > > What about Quote? Do we want to move it to CSVFormat? Makes sense because > it is really part of a CSVFormat. OTOH CSVFormat.Quote.ALL is more verb

[Parent] Build fails to run "jacoco" plugin

Hi. In project [Math], the command "mvn jacoco:check" fails, with the following error: ---CUT--- [INFO] Scanning for projects... [INFO] [INFO] Building Commons Math [INFO]task-segment: [jacoco:check] [INFO] -

Re: [csv] type name consistency

I like Csv as opposed to CSV also. On Tuesday, August 6, 2013, Gary Gregory wrote: > The class names in [csv] are (pp) means package private, others are public > > org.apache.commons.csv.Constants (pp) > org.apache.commons.csv.CSVFormat > org.apache.commons.csv.CSVLexer > org.apache.commons.csv.C

Re: [csv] final types

What exactly does it hurt by leaving them non-final? It's not like we have to support folks doing stupid things. One user doing something silly doesn't impact other users either. I guess I don't understand the paranoia here. On Tuesday, August 6, 2013, Torsten Curdt wrote: > >> I am also -0 to

[IMAGING] Tidied up SNAPSHOTS

I've removed the spurious 1.1-SNAPSHOT version. This was generated by Continuum, so trunk must have been updated to 1.1-SNAPSHOT at one point. I suspect that was caused by the Maven Release plugin. I also removed 1.0-SNAPSHOT and regenerated it. ---

Re: [MONITORING] Contiuum build still fails (was: Re: [continuum] BUILD FAILURE: Apache Commons - Commons Monitoring (Sandbox) - Monitoring requires Java 1.6 for its JDBC module)

On 7 August 2013 08:33, Benedikt Ritter wrote: > Hi, > > this still fails. Can one of you guys who is working on monitoring (Romain, > Matt, Oliver, James?!) fix this? > > I see three options: > - configure contiuum to use maven 3 > - use a version of the shade plugin that doesn't require maven 3

Re: [MONITORING] Contiuum build still fails (was: Re: [continuum] BUILD FAILURE: Apache Commons - Commons Monitoring (Sandbox) - Monitoring requires Java 1.6 for its JDBC module)

2013/8/7 Romain Manni-Bucau > Hi, > > i have no idea how continuum can be configured, is it hard to setup maven > 3? > Sorry, no idea either :-) I had hoped that you know... > > *Romain Manni-Bucau* > *Twitter: @rmannibucau * > *Blog: **http://rmannibucau.wordp

Re: [MONITORING] Contiuum build still fails (was: Re: [continuum] BUILD FAILURE: Apache Commons - Commons Monitoring (Sandbox) - Monitoring requires Java 1.6 for its JDBC module)

Hi, i have no idea how continuum can be configured, is it hard to setup maven 3? *Romain Manni-Bucau* *Twitter: @rmannibucau * *Blog: **http://rmannibucau.wordpress.com/* *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Githu

[MONITORING] Contiuum build still fails (was: Re: [continuum] BUILD FAILURE: Apache Commons - Commons Monitoring (Sandbox) - Monitoring requires Java 1.6 for its JDBC module)

Hi, this still fails. Can one of you guys who is working on monitoring (Romain, Matt, Oliver, James?!) fix this? I see three options: - configure contiuum to use maven 3 - use a version of the shade plugin that doesn't require maven 3 - don't use shade Benedikt 2013/8/7 Continuum@vmbuild > O

[continuum] BUILD FAILURE: Apache Commons - Commons Monitoring (Sandbox) - Monitoring requires Java 1.6 for its JDBC module

Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=27251&projectId=127 Build statistics: State: Failed Previous State: Failed Started at: Wed 7 Aug 2013 07:20:13 + Finished at: Wed 7 Aug 2013 07:20:24 + Total time: 11s Build Trigger: Schedule Buil