[jira] [Created] (MATH-1489) Test failure because of incompatible version specification of JaCoCo in pom.xml

2019-06-15 Thread M. Z. (JIRA)
M. Z. created MATH-1489:
---

 Summary: Test failure because of incompatible version 
specification of JaCoCo in pom.xml
 Key: MATH-1489
 URL: https://issues.apache.org/jira/browse/MATH-1489
 Project: Commons Math
  Issue Type: Bug
 Environment: OpenJDK 11.0.3

Debian GNU/Linux 9.9 stretch

 
Reporter: M. Z.
 Attachments: commons-math-buildlog-2019-06-15.log

I've experienced constant build failures on the attempt to "mvn clean package"

on a working copy of [http://gitbox.apache.org/repos/asf/commons-math.git] ( 
commit 4b0f52c0dd9df564d58140e1d717a2da218f0139 )

It has to do with the specified version of jacoco in pom.xml. See attached 
buildlog for concrete error.

My solution:

$ git diff

--- a/pom.xml
+++ b/pom.xml
@@ -493,7 +493,7 @@
 2.7.2
 
 
-    0.8.0
+    0.8.4 
 0.96
 0.8
 0.8

 

See 
[https://stackoverflow.com/questions/55272870/surefire-maven-plugin-corrupted-stdout-by-directly-writing-to-native-stream-in]
 for a previously reported issue with the use jacoco and OpenJDK 11.

After the proposed change, I've got

$ mvn clean package



[INFO] Results:
[INFO] 
[ERROR] Failures: 
[ERROR]   FastMathTest.checkMissingFastMathClasses:1275 FastMath should 
implement all StrictMath methods
[INFO] 
[ERROR] Tests run: 4864, Failures: 1, Errors: 0, Skipped: 31
[INFO] 
[INFO] 
[INFO] BUILD FAILURE
[INFO] 

...

So tests should have been executed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (CSV-245) Post 1.7 release fixes.

2019-06-15 Thread Gary Gregory (JIRA)


 [ 
https://issues.apache.org/jira/browse/CSV-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory closed CSV-245.

   Resolution: Fixed
Fix Version/s: 1.8

In git master.

> Post 1.7 release fixes.
> ---
>
> Key: CSV-245
> URL: https://issues.apache.org/jira/browse/CSV-245
> Project: Commons CSV
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Gary Gregory
>Priority: Major
> Fix For: 1.8
>
>
> * Fix checkstyle: remove tabs
> * Fix checkstyle: Split long line
> * Fix checkstyle: exclude pom.properties
> * Update findbugs to allow deliberate fall-through
> * Fix pmd: Remove ternary operator returning false
> * Fix pmd: Remove implicit final
> * Fix pmd: Ignore TooManyStaticImports.
> This requires adding the default ruleset and then modifying with
> suppressions.
> * Add tests to cover use of the IOUtils class.
> Requires the CSVFormat to have no quote or escape character, and the
> formatted value to be a java.io.Reader.
> * Clean-up findbugs exclude filter.
> * Removed unused import
> * Updated test comments for print tests targeting IOUtils.
> * Fix checkstyle: Suppress line length warning in CSVParser.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (CSV-245) Post 1.7 release fixes.

2019-06-15 Thread Gary Gregory (JIRA)
Gary Gregory created CSV-245:


 Summary: Post 1.7 release fixes.
 Key: CSV-245
 URL: https://issues.apache.org/jira/browse/CSV-245
 Project: Commons CSV
  Issue Type: Bug
Affects Versions: 1.7
Reporter: Gary Gregory


* Fix checkstyle: remove tabs
* Fix checkstyle: Split long line
* Fix checkstyle: exclude pom.properties
* Update findbugs to allow deliberate fall-through
* Fix pmd: Remove ternary operator returning false
* Fix pmd: Remove implicit final
* Fix pmd: Ignore TooManyStaticImports.

This requires adding the default ruleset and then modifying with
suppressions.

* Add tests to cover use of the IOUtils class.

Requires the CSVFormat to have no quote or escape character, and the
formatted value to be a java.io.Reader.

* Clean-up findbugs exclude filter.
* Removed unused import
* Updated test comments for print tests targeting IOUtils.
* Fix checkstyle: Suppress line length warning in CSVParser.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[GitHub] [commons-csv] garydgregory merged pull request #44: Post release fixes

2019-06-15 Thread GitBox
garydgregory merged pull request #44: Post release fixes
URL: https://github.com/apache/commons-csv/pull/44
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Updated] (BEANUTILS-520) BeanUtils2 mitigate CVE-2014-0114

2019-06-15 Thread Rob Tompkins (JIRA)


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Tompkins updated BEANUTILS-520:
---
Fix Version/s: 1.9.4

> BeanUtils2 mitigate CVE-2014-0114
> -
>
> Key: BEANUTILS-520
> URL: https://issues.apache.org/jira/browse/BEANUTILS-520
> Project: Commons BeanUtils
>  Issue Type: Improvement
>  Components: Bean / Property Utils
>Affects Versions: 1.9.3
>Reporter: Melloware
>Assignee: Rob Tompkins
>Priority: Major
>  Labels: security
> Fix For: 1.9.4, 2.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> https://nvd.nist.gov/vuln/detail/CVE-2014-0114
> Due to the above CVE in 1.9.2 they added a Suppression but it is still being 
> marked as a security risk through most major checks from OWASP and Sonatype 
> IQ.
> "commons-beanutils added a SuppressPropertiesBeanIntrospector which includes 
> a specialized instance of itself as the SUPPRESS_CLASS constant beginning in 
> version 1.9.2 that specifically suppresses the class property. +However, this 
> fix is not enabled by default.+"
> For BeanUtils2 why not make this the default and have people "enable" it if 
> it they want to get the feature.
> Thanks for your consideration.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (BEANUTILS-520) BeanUtils2 mitigate CVE-2014-0114

2019-06-15 Thread Rob Tompkins (JIRA)


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Tompkins resolved BEANUTILS-520.

Resolution: Fixed

> BeanUtils2 mitigate CVE-2014-0114
> -
>
> Key: BEANUTILS-520
> URL: https://issues.apache.org/jira/browse/BEANUTILS-520
> Project: Commons BeanUtils
>  Issue Type: Improvement
>  Components: Bean / Property Utils
>Affects Versions: 1.9.3
>Reporter: Melloware
>Assignee: Rob Tompkins
>Priority: Major
>  Labels: security
> Fix For: 1.9.4, 2.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> https://nvd.nist.gov/vuln/detail/CVE-2014-0114
> Due to the above CVE in 1.9.2 they added a Suppression but it is still being 
> marked as a security risk through most major checks from OWASP and Sonatype 
> IQ.
> "commons-beanutils added a SuppressPropertiesBeanIntrospector which includes 
> a specialized instance of itself as the SUPPRESS_CLASS constant beginning in 
> version 1.9.2 that specifically suppresses the class property. +However, this 
> fix is not enabled by default.+"
> For BeanUtils2 why not make this the default and have people "enable" it if 
> it they want to get the feature.
> Thanks for your consideration.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Reopened] (BEANUTILS-520) BeanUtils2 mitigate CVE-2014-0114

2019-06-15 Thread Rob Tompkins (JIRA)


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Tompkins reopened BEANUTILS-520:

  Assignee: Rob Tompkins

> BeanUtils2 mitigate CVE-2014-0114
> -
>
> Key: BEANUTILS-520
> URL: https://issues.apache.org/jira/browse/BEANUTILS-520
> Project: Commons BeanUtils
>  Issue Type: Improvement
>  Components: Bean / Property Utils
>Affects Versions: 1.9.3
>Reporter: Melloware
>Assignee: Rob Tompkins
>Priority: Major
>  Labels: security
> Fix For: 2.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> https://nvd.nist.gov/vuln/detail/CVE-2014-0114
> Due to the above CVE in 1.9.2 they added a Suppression but it is still being 
> marked as a security risk through most major checks from OWASP and Sonatype 
> IQ.
> "commons-beanutils added a SuppressPropertiesBeanIntrospector which includes 
> a specialized instance of itself as the SUPPRESS_CLASS constant beginning in 
> version 1.9.2 that specifically suppresses the class property. +However, this 
> fix is not enabled by default.+"
> For BeanUtils2 why not make this the default and have people "enable" it if 
> it they want to get the feature.
> Thanks for your consideration.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[GitHub] [commons-csv] coveralls edited a comment on issue #44: Post release fixes

2019-06-15 Thread GitBox
coveralls edited a comment on issue #44: Post release fixes
URL: https://github.com/apache/commons-csv/pull/44#issuecomment-501905854
 
 
   
   [![Coverage 
Status](https://coveralls.io/builds/24015244/badge)](https://coveralls.io/builds/24015244)
   
   Coverage increased (+1.7%) to 92.993% when pulling 
**e9e98f0050bd99fef8a9700bedf82828364760c4 on aherbert:post-release-fixes** 
into **42b9fdb099a438886842795d8b0b325952d9f3e9 on apache:master**.
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Resolved] (CSV-215) CSVRecord mutability

2019-06-15 Thread Sebb (JIRA)


 [ 
https://issues.apache.org/jira/browse/CSV-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb resolved CSV-215.
--
Resolution: Duplicate

> CSVRecord mutability
> 
>
> Key: CSV-215
> URL: https://issues.apache.org/jira/browse/CSV-215
> Project: Commons CSV
>  Issue Type: Improvement
>  Components: Parser
>Reporter: Nitin Mahendru
>Priority: Minor
>  Labels: features
>   Original Estimate: 16h
>  Remaining Estimate: 16h
>
> I recently pushed a change(pull request 20) to get the line ending from the 
> parser.
> Now I want to push another change which I feel will also be useful for the 
> community. I want to add a CSVRecordMutable class which had a constructor 
> which accepts a CSVRecord object. So when we have a CSVRecordMutable object 
> from it then we can edit individual columns using it.
> I would be using this to write back my edited CSV file. My use case is to 
> read a csv, mangle some columns, write back a new csv.
> I could have directly raised a pull request but I just wanted to float the 
> idea before and see the reaction.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (RNG-106) XorShiRo generators require non-zero input seeds

2019-06-15 Thread Alex D Herbert (JIRA)


 [ 
https://issues.apache.org/jira/browse/RNG-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex D Herbert resolved RNG-106.

Resolution: Implemented

In master.

 

> XorShiRo generators require non-zero input seeds
> 
>
> Key: RNG-106
> URL: https://issues.apache.org/jira/browse/RNG-106
> Project: Commons RNG
>  Issue Type: Improvement
>  Components: core, simple
>Affects Versions: 1.3
>Reporter: Alex D Herbert
>Assignee: Alex D Herbert
>Priority: Major
> Fix For: 1.3
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The following generators based on Xor shifts all require non-zero seeds:
> {noformat}
> XOR_SHIFT_1024_S
> XOR_SHIFT_1024_S_PHI
> XO_RO_SHI_RO_64_S
> XO_RO_SHI_RO_64_SS
> XO_SHI_RO_128_PLUS
> XO_SHI_RO_128_SS
> XO_RO_SHI_RO_128_PLUS
> XO_RO_SHI_RO_128_SS
> XO_SHI_RO_256_PLUS
> XO_SHI_RO_256_SS
> XO_SHI_RO_512_PLUS
> XO_SHI_RO_512_SS
> {noformat}
> A zero seed results in zero output for each call to the generator.
> Tests added to the rng-core module show that only a single bit is required to 
> be set and the generator is able to generate non-zero output. These tests are 
> simple and do not test the output for many cycles or do statistical analysis 
> on the output randomness. However the authors of the generators state that 
> they require a non-zero seed and are not any more specific so I assume that a 
> single bit is enough to maintain the internal state capable of randomness.
> This can be fixed with the following methods:
>  # Set the final bit in the seed to 1. This will be fast but loses 1 bit of 
> seed entropy.
>  # Check the seed array for zeros. If the entire array is zero then generate 
> a single seed value until it is non-zero in a loop and set it into the seed 
> array.
>  # Check the seed array for zeros. If the entire array is zero then 
> re-generate the seed using recursive method call.
> Note that this is an edge case. The smallest seed uses 64 bits, others use 
> 128, 256, 512, 1024 (the number of bits in the seed is the state size and is 
> the number in the enum). For the worst case this will occur 1 in 2^64 times.
> Here is the robust approach:
> {code:java}
> int[] seed;
> do {
> seed = createSeed(); // Appropriate seed array generation
> } while (SeedFactory.isZero(seed);
> return seed;
> {code}
> This would add new isZero(int[]) and isZero(long[]) methods to the seed 
> factory. The entire method for creating a non-zero array seed could be added 
> to the SeedFactory.
> Here is the compromise approach:
> {code:java}
> int[] seed = createSeed(); // Appropriate seed array generation
> if (SeedFactory.isZero(seed)) {
> do {
> seed[0] = SeedFactory.createInt();
> } while (seed[0] == 0);
> }
> {code}
> Given the loop will happen 1 in 2^64 times the speed of the two approaches 
> will differ due to how the JVM produces the final code for the hot path (i.e. 
> not the edge case).
> Here is the simple approach:
> {code:java}
> // Ensure non-zero (loses 1 bit of entropy)
> return createSeed() | 1;
> {code}
> Losing 1 bit of entropy is undesirable.
> A performance test of the approaches (and variants) should be done for 
> reference.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (CSV-213) CSVParser#iterator()#hasNext() fails

2019-06-15 Thread Sebb (JIRA)


 [ 
https://issues.apache.org/jira/browse/CSV-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb resolved CSV-213.
--
Resolution: Fixed

Reported as fixed

> CSVParser#iterator()#hasNext() fails
> 
>
> Key: CSV-213
> URL: https://issues.apache.org/jira/browse/CSV-213
> Project: Commons CSV
>  Issue Type: Bug
>  Components: Parser
>Affects Versions: 1.4
> Environment: linux/osx
>Reporter: Lukas Vasek
>Priority: Blocker
> Attachments: 999751170.patch.csv
>
>
> Hello,
> with class sample below and attached fail the program fails. Problem is that 
> iterator wrongly computes the records. If hasNext is true then next record 
> should be fetched.
> + wouldn't it be better to provide currentRecord also?
> {code:java}
> public class Test {
> private static final CSVFormat csvFormat =
> CSVFormat.DEFAULT
> .withDelimiter(';')
> .withFirstRecordAsHeader()
> .withRecordSeparator('\n')
> .withQuoteMode(QuoteMode.ALL);
> private static Optional createEndChannel(File csvFile) {
> try (Reader reader = new InputStreamReader(new 
> FileInputStream(csvFile), StandardCharsets.UTF_8);
>  CSVParser parser = new CSVParser(reader, csvFormat)) {
> if (parser.iterator().hasNext()) {
> System.out.println(parser.getCurrentLineNumber());
> System.out.println(parser.getRecordNumber());
> // get only first record we don't need other's
> CSVRecord firstRecord = parser.iterator().next(); // this 
> fails
> return Optional.of(null);
> }
> } catch (IOException e) {
> throw new RuntimeException("Error while adding end channel to 
> csv", e);
> }
> return Optional.empty();
> }
> public static void main(String[] args) {
> createEndChannel(new File("/tmp/999751170.patch.csv"));
> //createEndChannel(new File("/tmp/129441.csv"));
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[GitHub] [commons-rng] asfgit merged pull request #51: RNG-106: Ensure SeedFactory produces non-zero seed arrays.

2019-06-15 Thread GitBox
asfgit merged pull request #51: RNG-106: Ensure SeedFactory produces non-zero 
seed arrays.
URL: https://github.com/apache/commons-rng/pull/51
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Resolved] (CSV-198) Cannot parse file by header with custom delimiter on Java 1.6

2019-06-15 Thread Sebb (JIRA)


 [ 
https://issues.apache.org/jira/browse/CSV-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb resolved CSV-198.
--
Resolution: Information Provided

> Cannot parse file by header with custom delimiter on Java 1.6
> -
>
> Key: CSV-198
> URL: https://issues.apache.org/jira/browse/CSV-198
> Project: Commons CSV
>  Issue Type: Bug
>  Components: Parser
>Affects Versions: 1.4
> Environment: Java 1.6, Windows
>Reporter: Tadhg Pearson
>Priority: Major
>
> Reading a CSV file from the parser using the header line results in 
> "IllegalArgumentException: Mappng for  not found" - even when the 
> column exists in the file. In this case, we are using Java 1.6 and the file 
> uses the ^ symbol to delimit columns. This works correctly in Java 7 & Java 8.
> The code required to reproduce the issue is below. You can find the 
> optd_por_public.csv file referenced at 
> https://raw.githubusercontent.com/opentraveldata/opentraveldata/master/opentraveldata/optd_por_public.csv
> It will need to be on the classpath to run the unit test.  Hope that helps, 
> Tadhg
> You should get the following output
> --
> {code}
> java.lang.IllegalArgumentException: Mapping for location_type not found, 
> expected one of 
> [iata_code,icao_code,faa_code,is_geonames,geoname_id,envelope_id,name,asciiname,latitude,longitude,fclass,fcode,page_rank,date_from,date_until,comment,country_code,cc2,country_name,continent_name,adm1_code,adm1_name_utf,adm1_name_ascii,adm2_code,adm2_name_utf,adm2_name_ascii,adm3_code,adm4_code,population,elevation,gtopo30,timezone,gmt_offset,dst_offset,raw_offset,moddate,city_code_list,city_name_list,city_detail_list,tvl_por_list,state_code,location_type,wiki_link,alt_name_section,wac,wac_name]
>   at org.apache.commons.csv.CSVRecord.get(CSVRecord.java:104)
>   at com.amadeus.ui.CSVRecordTest.test(CSVRecordTest.java:31)
> {code}
> 
> {code:java}
> import static org.junit.Assert.assertNotNull;
> import java.io.IOException;
> import java.io.InputStream;
> import java.io.InputStreamReader;
> import java.io.UnsupportedEncodingException;
> import org.apache.commons.csv.CSVFormat;
> import org.apache.commons.csv.CSVParser;
> import org.apache.commons.csv.CSVRecord;
> import org.junit.Test;
> public class CSVRecordTest {
>   private static final CSVFormat CSV_FORMAT = 
> CSVFormat.EXCEL.withDelimiter('^').withFirstRecordAsHeader();
>   
>   @Test
>   public void test() throws UnsupportedEncodingException, IOException {
>   InputStream pointsOfReference = 
> getClass().getResourceAsStream("/optd_por_public.csv");
>   CSVParser parser = CSV_FORMAT.parse(new 
> InputStreamReader(pointsOfReference, "UTF-8"));
>   for (CSVRecord record : parser) {
>   String locationType = record.get("location_type");
>   assertNotNull(locationType);
>   }
>   }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (CSV-197) CSVParser doesn't close the underlying handle after iteration

2019-06-15 Thread Sebb (JIRA)


 [ 
https://issues.apache.org/jira/browse/CSV-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb resolved CSV-197.
--
Resolution: Won't Fix

Not a bug

> CSVParser doesn't close the underlying handle after iteration
> -
>
> Key: CSV-197
> URL: https://issues.apache.org/jira/browse/CSV-197
> Project: Commons CSV
>  Issue Type: Bug
>  Components: Parser
>Reporter: Prateek Rungta
>Priority: Minor
> Fix For: Patch Needed, Discussion, 1.x
>
>
> The following code leaks file handles:
> {code}
> CSVParser parser = // setup parser
> for (CSVRecord rec: parser) {
> }
> // leak
> {code}
> I'd expect the underlying iterator to close() if it's finished iterating. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CSV-185) SIte archives download links don't work

2019-06-15 Thread Sebb (JIRA)


[ 
https://issues.apache.org/jira/browse/CSV-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864695#comment-16864695
 ] 

Sebb commented on CSV-185:
--

The archived sites have also now disappeared.

> SIte archives download links don't work
> ---
>
> Key: CSV-185
> URL: https://issues.apache.org/jira/browse/CSV-185
> Project: Commons CSV
>  Issue Type: Bug
>Reporter: Sebb
>Priority: Major
>
> The CSV site includes links to archived versions of the site.
> These are copies of the sites for earlier versions, and as such, still 
> contain download link. These no longer work. Rather than fixing them to point 
> directly to the obsolete versions, the pages should document that the version 
> is no longer current



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (CSV-244) Test case failures following CSVFormat#equals() update

2019-06-15 Thread Sebb (JIRA)


 [ 
https://issues.apache.org/jira/browse/CSV-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb resolved CSV-244.
--
Resolution: Fixed

42b9fdb  CSV-244 Test case failures following CSVFormat#equals() update

> Test case failures following CSVFormat#equals() update
> --
>
> Key: CSV-244
> URL: https://issues.apache.org/jira/browse/CSV-244
> Project: Commons CSV
>  Issue Type: Bug
>Reporter: Sebb
>Priority: Major
>
> The CSVFormat#equals() method was recently updated to take account of 
> additions to the class state. This caused two test failures:
> [ERROR]   CSVFormatTest.testHashCodeAndWithIgnoreHeaderCase:523
> [ERROR]   CSVFormatTest.testWithHeaderComments:972
> These both assert equality of a format with another derived from it.
> The formats should only be equal if they have the same behaviour.
> This will no longer be the case if the derived format has a different setting.
> The checks need to be changed to assert inequality.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (CSV-244) Test case failures following CSVFormat#equals() update

2019-06-15 Thread Sebb (JIRA)
Sebb created CSV-244:


 Summary: Test case failures following CSVFormat#equals() update
 Key: CSV-244
 URL: https://issues.apache.org/jira/browse/CSV-244
 Project: Commons CSV
  Issue Type: Bug
Reporter: Sebb


The CSVFormat#equals() method was recently updated to take account of additions 
to the class state. This caused two test failures:

[ERROR]   CSVFormatTest.testHashCodeAndWithIgnoreHeaderCase:523
[ERROR]   CSVFormatTest.testWithHeaderComments:972

These both assert equality of a format with another derived from it.
The formats should only be equal if they have the same behaviour.
This will no longer be the case if the derived format has a different setting.

The checks need to be changed to assert inequality.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[GitHub] [commons-numbers] coveralls edited a comment on issue #48: [WIP] perform the actual migration to JUnit 5

2019-06-15 Thread GitBox
coveralls edited a comment on issue #48: [WIP] perform the actual migration to 
JUnit 5
URL: https://github.com/apache/commons-numbers/pull/48#issuecomment-500176439
 
 
   
   [![Coverage 
Status](https://coveralls.io/builds/24014006/badge)](https://coveralls.io/builds/24014006)
   
   Coverage decreased (-0.03%) to 94.347% when pulling 
**af0d00f2c8eb67361c90b34cae88e7c832397dfb on 
grimreaper:eax/simple-migrate-map** into 
**934be57412ff6ab9fd67f0eeeddba49895afff06 on apache:master**.
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [commons-numbers] grimreaper commented on issue #48: [WIP] perform the actual migration to JUnit 5

2019-06-15 Thread GitBox
grimreaper commented on issue #48: [WIP] perform the actual migration to JUnit 5
URL: https://github.com/apache/commons-numbers/pull/48#issuecomment-502343499
 
 
   > , on my part, am finished with this branch. Do you intend to work any 
further on it? If not, what to do next? Write to the dev mailing list? 
   
   Yes. We should send it to the list for review. After that we should squash 
the changes into a single commit and merge.
   
   
   > I guess the pom.xml will have to be modified to remove any dependency 
related to JUnit 4, but I'm not sure how, since I didn't understand all of the 
changes made to it when adding JUnit 5 as a dependency alongside JUnit 4.
   
   I'll follow up with that after the merge.
   
   >  From then on, I migrated the file from scratch, meaning I didn't include 
any of your later changes (this is exactly the scenario I wanted to avoid by 
agreeing on which pull request should be merged first before any major changes 
are performed in this branch that would conflict with the other pull request).
   
   Sorry about that. I got carried away and kind of forgot :/


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [commons-numbers] grimreaper commented on issue #48: [WIP] perform the actual migration to JUnit 5

2019-06-15 Thread GitBox
grimreaper commented on issue #48: [WIP] perform the actual migration to JUnit 5
URL: https://github.com/apache/commons-numbers/pull/48#issuecomment-502343526
 
 
   Also, thank you for all your help: you did the crux of the work.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services