date:20170815

Re: [CSV] CSVMutableRecord

2017-08-15 Thread Gary Gregory

On Tue, Aug 15, 2017 at 5:32 PM, Gilles 
wrote:

> On Tue, 15 Aug 2017 22:52:32 +, nitin mahendru wrote:
>
>> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
>>
>>> On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
>>> >>
 wrote:

>>>
>>> How about having a state in the class itself which says that it's
 mutable
 or not.
 If we call a setter on an immutable then it throws an exception.
 By default the records are immutable and you need to make them
 mutable
 using a new API.

>>>
>> A code example would be useful...
>>
>>
>>
>>
>> Below is the pull request I added.
>> https://github.com/apache/commons-csv/pull/21
>>
>
> As I indicated in the previous message, this is functionally
> breaking. [I'm diverting this discussion over to the "dev"
> mailing list.]
>

Saying that making record mutable is "breaking" is a bit unfair when we do
NOT document the mutability of the class in the first place.

Gary


>
> The following should be an interesting read:
>   http://markmail.org/message/6ytvmxvy2ndsfp7h
>
>
> Regards,
> Gilles
>
>
>
>
>> On Tue, Aug 15, 2017 at 11:17 AM Gilles 
>> wrote:
>>
>> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
>>> > On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
>>> > >> >> wrote:
>>> >
>>> >> How about having a state in the class itself which says that it's
>>> >> mutable
>>> >> or not.
>>> >> If we call a setter on an immutable then it throws an exception.
>>> >> By default the records are immutable and you need to make them
>>> >> mutable
>>> >> using a new API.
>>>
>>> A code example would be useful...
>>>
>>> >> pros: Saves memory, Keeps the immutability benefits
>>>
>>> What kind of usage are you considering that a single transient
>>> record matters (as compared to the ~300 MB of the JVM itself...)?
>>>
>>> >> cons: people using "mutable" records need to be careful.(While
>>> >> threading
>>> >> maybe)
>>> >>
>>> >
>>> > Interesting idea!
>>> >
>>> > But I think I like the idea of a subclass better if we are going to
>>> > split
>>> > the behavior b/w mutable and immutable.
>>>
>>> Once you have a subclass that is able to modify the state of
>>> its parent, it's a mutable object. Period.
>>> There is no such thing as a "split".
>>>
>>> >
>>> > For my money and the KISS principle, I would just add the put method
>>> > in
>>> > CSVRecord.
>>>
>>> Then, any use that assumes immutability will be broken.
>>>
>>>
>>> Gilles
>>>
>>>
>>> > Gary
>>> >
>>> >>
>>> >> -Nitin
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> On Tue, Aug 15, 2017 at 9:01 AM Gilles
>>> >> 
>>> >> wrote:
>>> >>
>>> >> > On Tue, 15 Aug 2017 09:49:04 -0600, Gary Gregory wrote:
>>> >> > > That looks odd to me. What comes up for me is the use case where
>>> >> I
>>> >> > > want to
>>> >> > > ETL a file of 10,000,000 records and update, say, one column. If
>>> >> am
>>> >> > > forced
>>> >> > > to create a brand new record for every record read, that would
>>> >> be a
>>> >> > > shame.
>>> >> >
>>> >> > Why?
>>> >> >
>>> >> > > If I had a mutable record, I could just keep on updating it and
>>> >> using
>>> >> > > it to
>>> >> > > write each row. Read record, update it, write record. No extra
>>> >> memory
>>> >> > > needed.
>>> >> >
>>> >> > How is the size of 1 additional record going to matter compared to
>>> >> the
>>> >> > size of the whole program?
>>> >> >
>>> >> > > Either we can make the current record mutable (what's the harm?)
>>> >> or
>>> >> > > we can
>>> >> > > make the parser serve out mutable records based on a config
>>> >> setting.
>>> >> > > This
>>> >> > > could be a subclass of CSVRecord with the extra method I
>>> >> proposed.
>>> >> >
>>> >> > The harm is that you loose all the promises of immutability.
>>> >> >
>>> >> > Regards,
>>> >> > Gilles
>>> >> >
>>> >> > >
>>> >> > > Thoughts?
>>> >> > >
>>> >> > > Gary
>>> >> > >
>>> >> > > On Tue, Aug 15, 2017 at 8:33 AM, Gilles
>>> >> > > 
>>> >> > > wrote:
>>> >> > >
>>> >> > >> On Tue, 15 Aug 2017 08:01:53 -0600, Gary Gregory wrote:
>>> >> > >>
>>> >> > >>> How does that work when you want to change more than one
>>> >> value?
>>> >> > >>>
>>> >> > >>
>>> >> > >> How about a "vararg" argument:
>>> >> > >>
>>> >> > >> /**
>>> >> > >>  * @param orig Original to be copied.
>>> >> > >>  * @param replace Fields to be replaced.
>>> >> > >>  */
>>> >> > >> public static CSVRecord createRecord(CSVRecord orig,
>>> >> > >>  Pair ...
>>> >> > >> replace) {
>>> >> > >> // ...
>>> >> > >> }
>>> >> > >>
>>> >> > >>
>>> >> > >> Gilles
>>> >> > >>
>>> >> > >>
>>> >> > >>
>>> >> > >>> Gary
>>> >> > >>>
>>> >> > >>> On Aug 15, 2017 00:17, "Benedikt Ritter" 
>>> >> > >>> wrote:
>>> >> > >>>
>>> >> > >>> Hi,
>>> >> > 
>>> >> >  I very much like that CSVRecord is

Re: [CSV] CSVMutableRecord

2017-08-15 Thread Gilles


On Tue, 15 Aug 2017 22:52:32 +, nitin mahendru wrote:

On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:

On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru


wrote:


On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
> On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
> > wrote:
>
>> How about having a state in the class itself which says that it's
>> mutable
>> or not.
>> If we call a setter on an immutable then it throws an exception.
>> By default the records are immutable and you need to make them
>> mutable
>> using a new API.

A code example would be useful...

>> pros: Saves memory, Keeps the immutability benefits

What kind of usage are you considering that a single transient
record matters (as compared to the ~300 MB of the JVM itself...)?

>> cons: people using "mutable" records need to be careful.(While
>> threading
>> maybe)
>>
>
> Interesting idea!
>
> But I think I like the idea of a subclass better if we are going 
to

> split
> the behavior b/w mutable and immutable.

Once you have a subclass that is able to modify the state of
its parent, it's a mutable object. Period.
There is no such thing as a "split".

>
> For my money and the KISS principle, I would just add the put 
method

> in
> CSVRecord.

Then, any use that assumes immutability will be broken.


Gilles


> Gary
>
>>
>> -Nitin
>>
>>
>>
>>
>> On Tue, Aug 15, 2017 at 9:01 AM Gilles
>> 
>> wrote:
>>
>> > On Tue, 15 Aug 2017 09:49:04 -0600, Gary Gregory wrote:
>> > > That looks odd to me. What comes up for me is the use case 
where

>> I
>> > > want to
>> > > ETL a file of 10,000,000 records and update, say, one column. 
If

>> am
>> > > forced
>> > > to create a brand new record for every record read, that 
would

>> be a
>> > > shame.
>> >
>> > Why?
>> >
>> > > If I had a mutable record, I could just keep on updating it 
and

>> using
>> > > it to
>> > > write each row. Read record, update it, write record. No 
extra

>> memory
>> > > needed.
>> >
>> > How is the size of 1 additional record going to matter compared 
to

>> the
>> > size of the whole program?
>> >
>> > > Either we can make the current record mutable (what's the 
harm?)

>> or
>> > > we can
>> > > make the parser serve out mutable records based on a config
>> setting.
>> > > This
>> > > could be a subclass of CSVRecord with the extra method I
>> proposed.
>> >
>> > The harm is that you loose all the promises of immutability.
>> >
>> > Regards,
>> > Gilles
>> >
>> > >
>> > > Thoughts?
>> > >
>> > > Gary
>> > >
>> > > On Tue, Aug 15, 2017 at 8:33 AM, Gilles
>> > > 
>> > > wrote:
>> > >
>> > >> On Tue, 15 Aug 2017 08:01:53 -0600, Gary Gregory wrote:
>> > >>
>> > >>> How does that work when you want to change more than one
>> value?
>> > >>>
>> > >>
>> > >> How about a "vararg" argument:
>> > >>
>> > >> /**
>> > >>  * @param orig Original to be copied.
>> > >>  * @param replace Fields to be replaced.
>> > >>  */
>> > >> public static CSVRecord createRecord(CSVRecord orig,
>> > >>  Pair 
...

>> > >> replace) {
>> > >> // ...
>> > >> }
>> > >>
>> > >>
>> > >> Gilles
>> > >>
>> > >>
>> > >>
>> > >>> Gary
>> > >>>
>> > >>> On Aug 15, 2017 00:17, "Benedikt Ritter" 


>> > >>> wrote:
>> > >>>
>> > >>> Hi,
>> > 
>> >  I very much like that CSVRecord is unmodifiable. So I’d
>> suggest an
>> >  API,
>> >  that creates a new record instead of mutating the existing
>> one:
>> > 
>> >  CSVRecord newRecord = myRecord.put(1, „value")
>> > 
>> >  I’m not sure about „put“ as a method name since it clashes
>> with
>> >  java.util.Map#put, which is mutation based...
>> > 
>> >  Regards,
>> >  Benedikt
>> > 
>> >  > Am 15.08.2017 um 02:54 schrieb Gary Gregory
>> >  :
>> >  >
>> >  > Feel free to provide a PR on GitHub :-)
>> >  >
>> >  > Gary
>> >  >
>> >  > On Aug 14, 2017 15:29, "Gary Gregory"
>> 
>> >  wrote:
>> >  >
>> >  >> I think we've kept the design as YAGNI as possible... 
:-)

>> >  >>
>> >  >> Gary
>> >  >>
>> >  >> On Mon, Aug 14, 2017

Re: [io] ClosedOutputStream#flush

2017-08-15 Thread Elijah Zupancic

Please omit this line from the program:

BufferedOutputStream bout = new BufferedOutputStream(fout, 9);

On Tue, Aug 15, 2017 at 6:12 PM, Elijah Zupancic  wrote:
> I inspected the code path and I think this bug has merit. Consider the
> following sample application:
>
> import org.apache.commons.io.IOUtils;
> import org.apache.commons.io.output.CloseShieldOutputStream;
>
> import java.io.BufferedOutputStream;
> import java.io.File;
> import java.io.FileInputStream;
> import java.io.FileOutputStream;
> import java.io.IOException;
> import java.nio.charset.StandardCharsets;
>
> public class BrokenShield {
> public static void main(String[] argv) throws IOException {
> File file = File.createTempFile("broken-shield", "txt");
>
> byte[] arbitraryData = "Hello World 
> ".getBytes(StandardCharsets.UTF_8);
>
> FileOutputStream fout = new FileOutputStream(file);
> BufferedOutputStream bout = new BufferedOutputStream(fout, 9);
> CloseShieldOutputStream cout = new CloseShieldOutputStream(fout);
>
> try {
> // This should work because we haven't tried to close the stream
> cout.write(arbitraryData);
>
> // Here we pretend this is some stupid library that insists on
> // closing a stream when it shouldn't.
> cout.close();
>
> // After we try to close the stream, new data can't be written to
> // the stream. For example: cout.write(arbitraryData);
> // Would throw an exception like:
> // java.io.IOException: write(72) failed: stream is closed
>
> // However, if we call flush(), no exception is thrown - this is
> // inconsistent with the behavior of write()
> cout.flush();
> } finally {
> // We properly close the stream we have to use the underlying
> // stream like you would expect.
> fout.close();
> }
>
> try (FileInputStream fin = new FileInputStream(file)) {
> String data = IOUtils.toString(fin, StandardCharsets.UTF_8);
> System.out.println(data);
> }
> }
> }
>
> On Thu, Aug 10, 2017 at 4:54 PM, Tomas Celaya  wrote:
>> Would anyone mind taking a look at this issue regarding the flush method on
>> ClosedOutputStream?
>>
>> https://issues.apache.org/jira/browse/IO-546
>>
>> The change is relatively trivial and the attached patch includes a test
>> case. I understand the impact is significant but I think it would make
>> ClosedOutputStream behave more consistently with what a user would expect.
>>
>> – Tomas Celaya

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

Re: [CSV] CSVMutableRecord

2017-08-15 Thread Gilles


On Tue, 15 Aug 2017 17:43:26 -0600, Gary Gregory wrote:
On Tue, Aug 15, 2017 at 5:32 PM, Gilles 


wrote:


On Tue, 15 Aug 2017 22:52:32 +, nitin mahendru wrote:


On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:


On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru


wrote:

On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:

> On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
> > wrote:
>
>> How about having a state in the class itself which says that 
it's

>> mutable
>> or not.
>> If we call a setter on an immutable then it throws an 
exception.

>> By default the records are immutable and you need to make them
>> mutable
>> using a new API.

A code example would be useful...

>> pros: Saves memory, Keeps the immutability benefits

What kind of usage are you considering that a single transient
record matters (as compared to the ~300 MB of the JVM itself...)?

>> cons: people using "mutable" records need to be careful.(While
>> threading
>> maybe)
>>
>
> Interesting idea!
>
> But I think I like the idea of a subclass better if we are going 
to

> split
> the behavior b/w mutable and immutable.

Once you have a subclass that is able to modify the state of
its parent, it's a mutable object. Period.
There is no such thing as a "split".

>
> For my money and the KISS principle, I would just add the put 
method

> in
> CSVRecord.

Then, any use that assumes immutability will be broken.


Gilles


> Gary
>
>>
>> -Nitin
>>
>>
>>
>>
>> On Tue, Aug 15, 2017 at 9:01 AM Gilles
>> 
>> wrote:
>>
>> > On Tue, 15 Aug 2017 09:49:04 -0600, Gary Gregory wrote:
>> > > That looks odd to me. What comes up for me is the use case 
where

>> I
>> > > want to
>> > > ETL a file of 10,000,000 records and update, say, one 
column. If

>> am
>> > > forced
>> > > to create a brand new record for every record read, that 
would

>> be a
>> > > shame.
>> >
>> > Why?
>> >
>> > > If I had a mutable record, I could just keep on updating it 
and

>> using
>> > > it to
>> > > write each row. Read record, update it, write record. No 
extra

>> memory
>> > > needed.
>> >
>> > How is the size of 1 additional record going to matter 
compared to

>> the
>> > size of the whole program?
>> >
>> > > Either we can make the current record mutable (what's the 
harm?)

>> or
>> > > we can
>> > > make the parser serve out mutable records based on a config
>> setting.
>> > > This
>> > > could be a subclass of CSVRecord with the extra method I
>> proposed.
>> >
>> > The harm is that you loose all the promises of immutability.
>> >
>> > Regards,
>> > Gilles
>> >
>> > >
>> > > Thoughts?
>> > >
>> > > Gary
>> > >
>> > > On Tue, Aug 15, 2017 at 8:33 AM, Gilles
>> > > 
>> > > wrote:
>> > >
>> > >> On Tue, 15 Aug 2017 08:01:53 -0600, Gary Gregory wrote:
>> > >>
>> > >>> How does that work when you want to change more than one
>> value?
>> > >>>
>> > >>
>> > >> How about a "vararg" argument:
>> > >>
>> > >> /**
>> > >>  * @param orig Original to be copied.
>> > >>  * @param replace Fields to be replaced.
>> > >>  */
>> > >> public static CSVRecord createRecord(CSVRecord orig,
>> > >>  Pair 
...

>> > >> replace) {
>> > >> // ...
>> > >> }
>> > >>
>> > >>
>> > >> Gilles
>> > >>
>> > >>
>> > >>
>> > >>> Gary
>> > >>>
>> > >>> On Aug 15, 2017 00:17, "Benedikt Ritter" 


>> > >>> wrote:
>> > >>>
>> > >>> Hi,
>> > 
>> >  I very much like that CSVRecord is unmodifiable. So I’d
>> suggest an
>> >  API,
>> >  that creates a new record instead of mutating the 
existing

>> one:
>> > 
>> >  CSVRecord newRecord = myRecord.put(1, „value")
>> > 
>> >  I’m not sure about „put“ as a method name since it 
clashes

>> with
>> >

Re: [io] ClosedOutputStream#flush

2017-08-15 Thread Elijah Zupancic

I inspected the code path and I think this bug has merit. Consider the
following sample application:

import org.apache.commons.io.IOUtils;
import org.apache.commons.io.output.CloseShieldOutputStream;

import java.io.BufferedOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.nio.charset.StandardCharsets;

public class BrokenShield {
public static void main(String[] argv) throws IOException {
File file = File.createTempFile("broken-shield", "txt");

byte[] arbitraryData = "Hello World ".getBytes(StandardCharsets.UTF_8);

FileOutputStream fout = new FileOutputStream(file);
BufferedOutputStream bout = new BufferedOutputStream(fout, 9);
CloseShieldOutputStream cout = new CloseShieldOutputStream(fout);

try {
// This should work because we haven't tried to close the stream
cout.write(arbitraryData);

// Here we pretend this is some stupid library that insists on
// closing a stream when it shouldn't.
cout.close();

// After we try to close the stream, new data can't be written to
// the stream. For example: cout.write(arbitraryData);
// Would throw an exception like:
// java.io.IOException: write(72) failed: stream is closed

// However, if we call flush(), no exception is thrown - this is
// inconsistent with the behavior of write()
cout.flush();
} finally {
// We properly close the stream we have to use the underlying
// stream like you would expect.
fout.close();
}

try (FileInputStream fin = new FileInputStream(file)) {
String data = IOUtils.toString(fin, StandardCharsets.UTF_8);
System.out.println(data);
}
}
}

On Thu, Aug 10, 2017 at 4:54 PM, Tomas Celaya  wrote:
> Would anyone mind taking a look at this issue regarding the flush method on
> ClosedOutputStream?
>
> https://issues.apache.org/jira/browse/IO-546
>
> The change is relatively trivial and the attached patch includes a test
> case. I understand the impact is significant but I think it would make
> ClosedOutputStream behave more consistently with what a user would expect.
>
> – Tomas Celaya

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

[All][Math] New component: "Commons Geometry"?

2017-08-15 Thread Gilles


Hello.

[Time for a new episode in our "Ripping CM" series.]

How about creating "Commons Geometry"?

The rationale is comprised of the usual suspects:
 * Smaller and more focused component, hence:
   - Consistent development and maintenance.
   - Consistent release schedule, not encumbered by
 changes (and endless discussions) in _totally_
 unrelated code.
   - Potential for attracting contributors not
 interested in maintaining the (growing) backlog
 of CM.
 * Self-contained: 96.3% of the "o.a.c.math4.geometry"
   package have no dependency except:
   - 4 classes now in "Commons Numbers".
   - 2 methods and 1 constant in "MathUtils".
   - CM exceptions. [Creating alternatives for those
 will probably be the most time-consuming part of
 the porting work.]

Moreover, none of the code in the "o.a.c.math4.geometry"
package is used by another package of CM.

A new component would give the "geometry" codes a much
better chance of being (confidently[1]) released, since
CM is "stuck" for the foreseeable future.[2]

WDYT?

Gilles

[1] There seems to be only one issue reported in JIRA
that pertains to "geometry".
[2] 54 issues yet to be fixed before the 4.0 release;
which, at the current rate, would lead to after 2025
(a very rough guess, I admit).


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

Re: REMINDER: [VOTE] Release Apache Commons JCS 2.2 based on RC1

2017-08-15 Thread Bruno P. Kinoshita

Had a bit of time while waiting for a training to begin here. So quickly 
executed tests (mvn clean test install -e -X) with Oracle 7/8, and IBM 7.


All tests passing in IBM JDK7 and Oracle JDK7. One test failed for Oracle JDK8. 
I'm running these in a Ubuntu LTS, running as 6GB mem 4CPU elastic disk 
VirtualBox VM, guest is a 32GB mem 8 core Windows 10. Results below.


Enrivonment (IBM JDK7):

Apache Maven 3.3.9
Maven home: /usr/share/maven
Java version: 1.7.0, vendor: IBM Corporation
Java home: /opt/ibm/java-x86_64-70/jre
Default locale: en_NZ, platform encoding: UTF-8
OS name: "linux", version: "4.10.0-30-generic", arch: "amd64", family: "unix"

OK!


Environment (Oracle JDK7):

Apache Maven 3.3.9
Maven home: /usr/share/maven
Java version: 1.7.0_80, vendor: Oracle Corporation
Java home: /opt/jdk1.7.0_80/jre
Default locale: en_NZ, platform encoding: UTF-8
OS name: "linux", version: "4.10.0-30-generic", arch: "amd64", family: "unix"

OK!


Environment (Oracle JDK8):

Apache Maven 3.3.9
Maven home: /usr/share/maven
Java version: 1.8.0_131, vendor: Oracle Corporation
Java home: /opt/jdk1.8.0_131/jre
Default locale: en_NZ, platform encoding: UTF-8
OS name: "linux", version: "4.10.0-30-generic", arch: "amd64", family: "unix"

Results :

Failed tests: 
  
IndexedDiskCacheConcurrentUnitTest$3.runTest:104->IndexedDiskCacheConcurrentUnitTest.runTestForRegion:184
 Removed key should be null: 41:key
stats Region Name = indexedRegion3
HitCountRam = 102
HitCountAux = 768
---Memory Cache
Put Count = 1274
Hit Count = 102
Miss Count = 943
Map Size = 100
List Size = 100
---Indexed Disk Cache
Is Alive = true
Key Map Size = 154
Data File Length = 175010
Max Key Size = 5000
Hit Count = 217
Bytes Free = 98782
Optimize Operation Count = 0
Times Optimized = 0
Recycle Count = 1
Recycle Bin Size = 200
Startup Size = 0
Purgatory Hits = 685
Purgatory Size = 301
Working = true
Alive = true
Empty = false
Size = 623

Tests run: 402, Failures: 1, Errors: 0, Skipped: 0

[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache Commons JCS . SUCCESS [15:01 min]
[INFO] Apache Commons JCS :: Core . FAILURE [03:02 min]
[INFO] Apache Commons JCS :: JCache ... SKIPPED
[INFO] Apache Commons JCS :: JCache TCK ... SKIPPED
[INFO] Apache Commons JCS :: JCache Extras  SKIPPED
[INFO] Apache Commons JCS :: JCache OpenJPA ... SKIPPED
[INFO] Apache Commons JCS :: Distribution . SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 18:04 min
[INFO] Finished at: 2017-08-15T17:42:41+12:00
[INFO] Final Memory: 62M/562M
[INFO] 


CheersBruno


On Tuesday, 15 August 2017, 6:15:23 AM NZST, Thomas Vandahl  
wrote:


We are one PMC vote short. Please consider voting.

On 02.08.17 15:32, Thomas Vandahl wrote:
> I would like to release the [jcs] component to resolve some overdue bugs
> 
> Apache Commons JCS 2.2 RC1 is available for review at:
>  https://dist.apache.org/repos/dist/dev/commons/jcs/ (r20728).
> 
> Maven artifacts are at:
>  https://repository.apache.org/content/repositories/orgapachecommons-1256 .
> 
> The Subversion tag is:
> 
> https://svn.apache.org/repos/asf/commons/proper/jcs/tags/commons-jcs-2.2
> (r1803806).
> 
> The release notes are at:
> 
> https://svn.apache.org/repos/asf/commons/proper/jcs/tags/commons-jcs-2.2/RELEASE-NOTES.txt
> (r1803806).
> 
> The staged site is available as a tarball at
> 
> https://dist.apache.org/repos/dist/dev/commons/jcs/commons-jcs-site-2.2.tar.gz
> (r20723).
> 
> Please review the release candidate and vote.
> 
>  [ ] +1 Release these artifacts
>  [ ] +0 OK, but...
>  [ ] -0 OK, but really should fix...
>  [ ] -1 I oppose this release because...
> 
> Bye, Thomas
> 
> -
> 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: REMINDER: [VOTE] Release Apache Commons JCS 2.2 based on RC1

2017-08-15 Thread Bruno P. Kinoshita

Forgot to mention that checked out the project with `svn co 
https://svn.apache.org/repos/asf/commons/proper/jcs/tags/commons-jcs-2.2`
Bruno


On Tuesday, 15 August 2017, 6:02:32 PM NZST, Bruno P. Kinoshita 
 wrote:

Had a bit of time while waiting for a training to begin here. So quickly 
executed tests (mvn clean test install -e -X) with Oracle 7/8, and IBM 7.


All tests passing in IBM JDK7 and Oracle JDK7. One test failed for Oracle JDK8. 
I'm running these in a Ubuntu LTS, running as 6GB mem 4CPU elastic disk 
VirtualBox VM, guest is a 32GB mem 8 core Windows 10. Results below.


Enrivonment (IBM JDK7):

Apache Maven 3.3.9
Maven home: /usr/share/maven
Java version: 1.7.0, vendor: IBM Corporation
Java home: /opt/ibm/java-x86_64-70/jre
Default locale: en_NZ, platform encoding: UTF-8
OS name: "linux", version: "4.10.0-30-generic", arch: "amd64", family: "unix"

OK!


Environment (Oracle JDK7):

Apache Maven 3.3.9
Maven home: /usr/share/maven
Java version: 1.7.0_80, vendor: Oracle Corporation
Java home: /opt/jdk1.7.0_80/jre
Default locale: en_NZ, platform encoding: UTF-8
OS name: "linux", version: "4.10.0-30-generic", arch: "amd64", family: "unix"

OK!


Environment (Oracle JDK8):

Apache Maven 3.3.9
Maven home: /usr/share/maven
Java version: 1.8.0_131, vendor: Oracle Corporation
Java home: /opt/jdk1.8.0_131/jre
Default locale: en_NZ, platform encoding: UTF-8
OS name: "linux", version: "4.10.0-30-generic", arch: "amd64", family: "unix"

Results :

Failed tests: 
  
IndexedDiskCacheConcurrentUnitTest$3.runTest:104->IndexedDiskCacheConcurrentUnitTest.runTestForRegion:184
 Removed key should be null: 41:key
stats Region Name = indexedRegion3
HitCountRam = 102
HitCountAux = 768
---Memory Cache
Put Count = 1274
Hit Count = 102
Miss Count = 943
Map Size = 100
List Size = 100
---Indexed Disk Cache
Is Alive = true
Key Map Size = 154
Data File Length = 175010
Max Key Size = 5000
Hit Count = 217
Bytes Free = 98782
Optimize Operation Count = 0
Times Optimized = 0
Recycle Count = 1
Recycle Bin Size = 200
Startup Size = 0
Purgatory Hits = 685
Purgatory Size = 301
Working = true
Alive = true
Empty = false
Size = 623

Tests run: 402, Failures: 1, Errors: 0, Skipped: 0

[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache Commons JCS . SUCCESS [15:01 min]
[INFO] Apache Commons JCS :: Core . FAILURE [03:02 min]
[INFO] Apache Commons JCS :: JCache ... SKIPPED
[INFO] Apache Commons JCS :: JCache TCK ... SKIPPED
[INFO] Apache Commons JCS :: JCache Extras  SKIPPED
[INFO] Apache Commons JCS :: JCache OpenJPA ... SKIPPED
[INFO] Apache Commons JCS :: Distribution . SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 18:04 min
[INFO] Finished at: 2017-08-15T17:42:41+12:00
[INFO] Final Memory: 62M/562M
[INFO] 


CheersBruno


On Tuesday, 15 August 2017, 6:15:23 AM NZST, Thomas Vandahl  
wrote:


We are one PMC vote short. Please consider voting.

On 02.08.17 15:32, Thomas Vandahl wrote:
> I would like to release the [jcs] component to resolve some overdue bugs
> 
> Apache Commons JCS 2.2 RC1 is available for review at:
>  https://dist.apache.org/repos/dist/dev/commons/jcs/ (r20728).
> 
> Maven artifacts are at:
>  https://repository.apache.org/content/repositories/orgapachecommons-1256 .
> 
> The Subversion tag is:
> 
> https://svn.apache.org/repos/asf/commons/proper/jcs/tags/commons-jcs-2.2
> (r1803806).
> 
> The release notes are at:
> 
> https://svn.apache.org/repos/asf/commons/proper/jcs/tags/commons-jcs-2.2/RELEASE-NOTES.txt
> (r1803806).
> 
> The staged site is available as a tarball at
> 
> https://dist.apache.org/repos/dist/dev/commons/jcs/commons-jcs-site-2.2.tar.gz
> (r20723).
> 
> Please review the release candidate and vote.
> 
>  [ ] +1 Release these artifacts
>  [ ] +0 OK, but...
>  [ ] -0 OK, but really should fix...
>  [ ] -1 I oppose this release because...
> 
> Bye, Thomas
> 
> -
> 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: [CSV] CSVMutableRecord

Re: [CSV] CSVMutableRecord

Re: [io] ClosedOutputStream#flush

Re: [CSV] CSVMutableRecord

Re: [io] ClosedOutputStream#flush

[All][Math] New component: "Commons Geometry"?

Re: REMINDER: [VOTE] Release Apache Commons JCS 2.2 based on RC1

Re: REMINDER: [VOTE] Release Apache Commons JCS 2.2 based on RC1

8 matches

Site Navigation

Mail list logo

Footer information