[GitHub] commons-lang issue #369: Update reflect tests to JUnit Jupiter
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/369 [](https://coveralls.io/builds/19395453) Coverage increased (+0.007%) to 95.259% when pulling **cbc8e0b2952164f97779c9a5fadca6acd2600ae2 on mureinik:junit-jupiter-reflect** into **884d273f4207095f881167b3398fc2a55617ee9a on apache:master**. ---
[GitHub] commons-lang pull request #369: Update reflect tests to JUnit Jupiter
GitHub user mureinik opened a pull request: https://github.com/apache/commons-lang/pull/369 Update reflect tests to JUnit Jupiter Upgrade the tests in the `reflect` package to use JUnit Jupiter as part of the effort to remove the dependency on the Vintage Engine. While most of these changes are drop-in replacements with no functional benefit, there are some non-obvious changes worth mentioning. Unlike `org.junit.Test`, `org.junit.jupiter.api.Test` does not have an `expected` argument. Instead, an explicit call to `org.junit.jupiter.api.Assertions.assertThrows` is used. Unlike `org.junit.Assume`, `org.junit.jupiter.api.Assumptions` does not have an `assumeNotNull` method. Instead, `assumeTrue` was used with an explicit condition of a variable being different than `null`. It's also worth noting this is a minimal patch for migrating the package's tests to Jupiter. There are several tests that can be made more elegant with Jupiter's new features, but that work is left for subsequent patches. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mureinik/commons-lang junit-jupiter-reflect Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/369.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #369 commit cbc8e0b2952164f97779c9a5fadca6acd2600ae2 Author: Allon Mureinik Date: 2018-10-02T03:41:37Z Update reflect tests to JUnit Jupiter Upgrade the tests in the reflect package to use JUnit Jupiter as part of the effort to remove the dependency on the Vintage Engine. While most of these changes are drop-in replacements with no functional benefit, there are some non-obvious changes worth mentioning. Unlike org.junit.Test, org.junit.jupiter.api.Test does not have an "expected" argument. Instead, an explicit call to org.junit.jupiter.api.Assertions.assertThrows is used. Unlike org.junit.Assume, org.junit.jupiter.api.Assumptions does not have an assumtNotNull method. Instead, assumeTrue was used with an explicit condition of a variable being different than null. It's also worth noting this is a minimal patch for migrating the package's tests to Jupiter. There are several tests that can be made more elegant with Jupiter's new features, but that work is left for subsequent patches. ---
[jira] [Comment Edited] (CSV-208) Cannot parse PostgreSQL CSV and Text formats
[
https://issues.apache.org/jira/browse/CSV-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16641162#comment-16641162
]
Jurrie Overgoor edited comment on CSV-208 at 10/7/18 8:32 PM:
--
I'm running into the same issue.
I'm now using the the following format:
{code:java}
CSVFormat.POSTGRESQL_CSV.withEscape('\\');
{code}
It seems to work ok.
So the bug is in the defautl formatters. I [submitted a simple
PR|https://github.com/apache/commons-csv/pull/32], but integration tests seem
to fail for reasons unclear to me.
But it exposes another issue: you can assign the quote and the escape character
the same character. This is not supported. So either you should get an
IllegalArgumentException, or it should be supported by commons-csv I feel.
was (Author: jurrieovergoor):
I'm running into the same issue.
I'm now using the the following format:
{code:java}
CSVFormat.POSTGRESQL_CSV.withEscape('\\');
{code}
It seems to work ok.
So the bug is in the defautl formatters. But it exposes another issue: you can
assign the quote and the escape character the same character. This is not
supported. So either you should get an IllegalArgumentException, or it should
be supported by commons-csv I feel.
> Cannot parse PostgreSQL CSV and Text formats
>
>
> Key: CSV-208
> URL: https://issues.apache.org/jira/browse/CSV-208
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Reporter: Gary Gregory
>Priority: Major
> Attachments: CSVFormatTest.java
>
>
> Cannot parse PostgreSQL CSV and Text formats.
> We cannot seem to parse the stock PostgreSQL Text format, see
> - org.apache.commons.csv.CSVPrinterTest.testRandomPostgreSqlCsv()
> - org.apache.commons.csv.CSVPrinterTest.testRandomPostgreSqlText()
> - org.apache.commons.csv.CSVPrinterTest.testPostgreSqlCsvNullOutput()
> - org.apache.commons.csv.CSVPrinterTest.testPostgreSqlCsvTextOutput()
> I am guessing that the issue is that in PostgreSQL, the escape character is
> the same as the quote character:
> {quote}
> QUOTE
> Specifies the quoting character to be used when a data value is quoted. The
> default is double-quote. This must be a single one-byte character. This
> option is allowed only when using CSV format.
> ESCAPE
> Specifies the character that should appear before a data character that
> matches the QUOTE value. The default is the same as the QUOTE value (so that
> the quoting character is doubled if it appears in the data). This must be a
> single one-byte character. This option is allowed only when using CSV format.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CSV-232) Site link "Source Repository" does not work
Jurrie Overgoor created CSV-232: --- Summary: Site link "Source Repository" does not work Key: CSV-232 URL: https://issues.apache.org/jira/browse/CSV-232 Project: Commons CSV Issue Type: Bug Components: Documentation Reporter: Jurrie Overgoor The link https://commons.apache.org/proper/commons-csv/source-repository.html (which is in the menu on the left hand side of https://commons.apache.org/proper/commons-csv/) does not work. I get a 404 - Not found. For anyone seeing this, the sources are available at https://github.com/apache/commons-csv -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16641196#comment-16641196
]
Matt Juntunen commented on GEOMETRY-14:
---
{quote}What are the different use-cases? Having had a quick look at {{Point3D}}
and {{Vector3}}, they seem fairly similar in their API and fairly convoluted in
their inheritance hierarchy.
{quote}
It surprises me that this seems new since we've discussed the point/vector API
quite a bit. Are you asking what's the difference between the usage of
{{Point?D}} and {{Vector?D}}? If so, the difference is mathematical: points
represent locations in space and vectors represent translations and directions.
Not many operations are allowed on points but vectors come with the full range
of operations allowed on vector spaces in linear algebra. Transformations can
be applied to both types, so {{AffineTransform?D}} needs to support both.
{quote}When we wonder whether an {{AffineTransform3D}} _is-a_
{{UnaryOperator}} or {{UnaryOperator}}, there is some alarm
starting to ring...
{quote}
It's logically both. However, the language doesn't directly support this so we
need to figure something else out. I don't see anything wrong with that.
As a side note, I'm planning on making the {{AffineTransform?D}} classes
implement {{o.a.c.g.core.partitioning.Transform}} as well, which means that we
will also have the method {{apply(Hyperplane<>)}}.
{quote}re: transform sequences
{quote}
I think that users should nearly always want to combine transform sequences
into a single transform instead of applying multiple transforms in order. For
example, with the current implementation of {{AffineTransform3D}}, the number
of multiplications involved in transforming a point with multiple transforms
applied one after another is {{9nt}} where {{n}} is the number of points and
{{t}} is the number of transforms. When combining transforms together, the
{{t}} value drops out and this becomes {{9n + 36}}, where {{n}} is again the
number of points and the {{36}} value is the one-time cost of multiplying the
transform matrices together. So, even with the simplest case of applying two
transforms in order, the combination method becomes the better choice when {{n
> 4}}. The difference becomes even more pronounced as more transforms are
involved and {{n}} increases.
Also, the combination approach has the benefit that an inverse can be
calculated that undoes _all_ of the combined transformations. This cannot be
done easily with a simple sequence of transforms.
I say all of this to make the point that we may not be losing a lot if
{{AffineTransform?D}} does not implement {{UnaryOperator}}. The function
composition and chaining provided by the latter does not quite fit our use case.
{quote}Also, have you already looked at how e.g.
# existing classes such as {{Rotation}} fit with {{AffineTransform3D}}
# usage of {{Quaternion}} (from ["Commons
Numbers"|https://git1-us-west.apache.org/repos/asf?p=commons-numbers.git;a=blob;f=commons-numbers-quaternion/src/main/java/org/apache/commons/numbers/quaternion/Quaternion.java;h=86d7fdfa53d2b61bd07cebd05c02008f2809ebd9;hb=HEAD]){quote}
Yes, I have. I'm planning on getting the API sorted with translations and scale
operations before jumping into that.
> AffineTransform?D Classes
> -
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> Pull Request #1: https://github.com/apache/commons-geometry/pull/14
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-466) Opening of a very large zip file is extremely slow compared to java.util.zip.ZipFile
[
https://issues.apache.org/jira/browse/COMPRESS-466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16641193#comment-16641193
]
Jakob Sultan Ericsson commented on COMPRESS-466:
Looks good and is working fine.
Thanks. You did a better refactor than I dared to do. :-)
> Opening of a very large zip file is extremely slow compared to
> java.util.zip.ZipFile
>
>
> Key: COMPRESS-466
> URL: https://issues.apache.org/jira/browse/COMPRESS-466
> Project: Commons Compress
> Issue Type: Bug
> Components: Compressors
>Affects Versions: 1.18
> Environment: Tested both on Linux and OSX 10.13.6.
>Reporter: Jakob Sultan Ericsson
>Priority: Major
>
> We have a quite large zip file 35 gb and try to open this with ZipFile.
> {code:java}
> try (ZipFile zf = new ZipFile(new File("35gb.zip"))) {
> System.out.println("File opened..." + (System.currentTimeMillis()
> - start));
> }
> {code}
> This code takes about 300 000 - 400 000 ms (5-6 minutes).
> If I run this with JDK-builtin java.util.zip.ZipFile, same code takes 300 ms
> (less than a second).
> I'm not totally sure what it is the problem but I did some debugging and
> basically all time is spent in
> {code:java}
> private void resolveLocalFileHeaderData(final Map NameAndComment> entriesWithoutUTF8Flag)
> {code}
> Anything that can be done to improve this?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-466) Opening of a very large zip file is extremely slow compared to java.util.zip.ZipFile
[
https://issues.apache.org/jira/browse/COMPRESS-466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16641163#comment-16641163
]
Stefan Bodewig commented on COMPRESS-466:
-
I've just committed my version of the patch to master. It would be good if you
could give it a try.
> Opening of a very large zip file is extremely slow compared to
> java.util.zip.ZipFile
>
>
> Key: COMPRESS-466
> URL: https://issues.apache.org/jira/browse/COMPRESS-466
> Project: Commons Compress
> Issue Type: Bug
> Components: Compressors
>Affects Versions: 1.18
> Environment: Tested both on Linux and OSX 10.13.6.
>Reporter: Jakob Sultan Ericsson
>Priority: Major
>
> We have a quite large zip file 35 gb and try to open this with ZipFile.
> {code:java}
> try (ZipFile zf = new ZipFile(new File("35gb.zip"))) {
> System.out.println("File opened..." + (System.currentTimeMillis()
> - start));
> }
> {code}
> This code takes about 300 000 - 400 000 ms (5-6 minutes).
> If I run this with JDK-builtin java.util.zip.ZipFile, same code takes 300 ms
> (less than a second).
> I'm not totally sure what it is the problem but I did some debugging and
> basically all time is spent in
> {code:java}
> private void resolveLocalFileHeaderData(final Map NameAndComment> entriesWithoutUTF8Flag)
> {code}
> Anything that can be done to improve this?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CSV-208) Cannot parse PostgreSQL CSV and Text formats
[
https://issues.apache.org/jira/browse/CSV-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16641162#comment-16641162
]
Jurrie Overgoor commented on CSV-208:
-
I'm running into the same issue.
I'm now using the the following format:
{code:java}
CSVFormat.POSTGRESQL_CSV.withEscape('\\');
{code}
It seems to work ok.
So the bug is in the defautl formatters. But it exposes another issue: you can
assign the quote and the escape character the same character. This is not
supported. So either you should get an IllegalArgumentException, or it should
be supported by commons-csv I feel.
> Cannot parse PostgreSQL CSV and Text formats
>
>
> Key: CSV-208
> URL: https://issues.apache.org/jira/browse/CSV-208
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Reporter: Gary Gregory
>Priority: Major
> Attachments: CSVFormatTest.java
>
>
> Cannot parse PostgreSQL CSV and Text formats.
> We cannot seem to parse the stock PostgreSQL Text format, see
> - org.apache.commons.csv.CSVPrinterTest.testRandomPostgreSqlCsv()
> - org.apache.commons.csv.CSVPrinterTest.testRandomPostgreSqlText()
> - org.apache.commons.csv.CSVPrinterTest.testPostgreSqlCsvNullOutput()
> - org.apache.commons.csv.CSVPrinterTest.testPostgreSqlCsvTextOutput()
> I am guessing that the issue is that in PostgreSQL, the escape character is
> the same as the quote character:
> {quote}
> QUOTE
> Specifies the quoting character to be used when a data value is quoted. The
> default is double-quote. This must be a single one-byte character. This
> option is allowed only when using CSV format.
> ESCAPE
> Specifies the character that should appear before a data character that
> matches the QUOTE value. The default is the same as the QUOTE value (so that
> the quoting character is doubled if it appears in the data). This must be a
> single one-byte character. This option is allowed only when using CSV format.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] commons-lang issue #368: Update exception tests to JUnit Jupiter
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/368 Thanks! ð ---
[GitHub] commons-lang pull request #368: Update exception tests to JUnit Jupiter
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/368 ---
[jira] [Commented] (COMPRESS-466) Opening of a very large zip file is extremely slow compared to java.util.zip.ZipFile
[
https://issues.apache.org/jira/browse/COMPRESS-466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16641124#comment-16641124
]
Jakob Sultan Ericsson commented on COMPRESS-466:
Yes i realized that. :-) I have made working patch last week but I forgot to
update this on my fork. I can publish it later tonight.
I also tested to read everything in one go and parse from memory it was a bit
faster but not as much as I thought.
18s with only read from central directory and about 12s from memory.
> Opening of a very large zip file is extremely slow compared to
> java.util.zip.ZipFile
>
>
> Key: COMPRESS-466
> URL: https://issues.apache.org/jira/browse/COMPRESS-466
> Project: Commons Compress
> Issue Type: Bug
> Components: Compressors
>Affects Versions: 1.18
> Environment: Tested both on Linux and OSX 10.13.6.
>Reporter: Jakob Sultan Ericsson
>Priority: Major
>
> We have a quite large zip file 35 gb and try to open this with ZipFile.
> {code:java}
> try (ZipFile zf = new ZipFile(new File("35gb.zip"))) {
> System.out.println("File opened..." + (System.currentTimeMillis()
> - start));
> }
> {code}
> This code takes about 300 000 - 400 000 ms (5-6 minutes).
> If I run this with JDK-builtin java.util.zip.ZipFile, same code takes 300 ms
> (less than a second).
> I'm not totally sure what it is the problem but I did some debugging and
> basically all time is spent in
> {code:java}
> private void resolveLocalFileHeaderData(final Map NameAndComment> entriesWithoutUTF8Flag)
> {code}
> Anything that can be done to improve this?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] commons-lang issue #368: Update exception tests to JUnit Jupiter
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/368 [](https://coveralls.io/builds/19392802) Coverage remained the same at 95.253% when pulling **884d273f4207095f881167b3398fc2a55617ee9a on mureinik:junit-jupiter-exception** into **762641dcdbae9456aa2b72ec8fa1baa0acab942f on apache:master**. ---
[GitHub] commons-lang pull request #368: Update exception tests to JUnit Jupiter
GitHub user mureinik opened a pull request: https://github.com/apache/commons-lang/pull/368 Update exception tests to JUnit Jupiter Upgrade the tests in the `exception` package to use JUnit Jupiter as part of the effort to remove the dependency on the Vintage Engine. While most of these changes are drop-in replacements with no functional benefit, there are some non-obvious changes worth mentioning. Unlike `org.junit.Test`, `org.junit.jupiter.api.Test` does not have an `expected` argument. Instead, an explicit call to `org.junit.jupiter.api.Assertions.assertThrows` is used. Another non-obvious change was performed in `ContextedRuntimeExceptionTest`. Unlike JUnit Vintage's `@Before`, JUnit Jupiter's `@BeforeEach` does not apply if a parent's method is annotated with it and the overriding method is not, so an explicit `@BeforeEach` annotation had to be added to `ContexedTuntimeExceptionTest#setUp()`. It's also worth noting this is a minimal patch for migrating the package's tests to Jupiter. There are several tests that can be made more elegant with Jupiter's new features, but that work is left for subsequent patches. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mureinik/commons-lang junit-jupiter-exception Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/368.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #368 commit 884d273f4207095f881167b3398fc2a55617ee9a Author: Allon Mureinik Date: 2018-10-02T03:41:37Z Update exception tests to JUnit Jupiter Upgrade the tests in the exception package to use JUnit Jupiter as part of the effort to remove the dependency on the Vintage Engine. While most of these changes are drop-in replacements with no functional benefit, there are some non-obvious changes worth mentioning. Unlike org.junit.Test, org.junit.jupiter.api.Test does not have an "expected" argument. Instead, an explicit call to org.junit.jupiter.api.Assertions.assertThrows is used. Another non-obvious change was performed in ContextedRuntimeExceptionTest. Unlike JUnit Vintages's @Before, JUnit Jupiter's @BeforeEach does not apply if a parent's method is annotated with it and the overriding method is not, so an explicit @BeforeEach annotation had to be added to ContexedTuntimeExceptionTest#setUp(). It's also worth noting this is a minimal patch for migrating the package's tests to Jupiter. There are several tests that can be made made more elegant with Jupiter's new features, but that work is left for subsequent patches. ---
[jira] [Commented] (COMPRESS-466) Opening of a very large zip file is extremely slow compared to java.util.zip.ZipFile
[
https://issues.apache.org/jira/browse/COMPRESS-466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16641106#comment-16641106
]
Stefan Bodewig commented on COMPRESS-466:
-
I'm afraid there is more to it. In your version {{ZipFile.getEntry}} is going
to always return {{null}} as {{nameMap}} hasn't been populated and we need a
few more adjustments. I'm using your patch as a starting point for adding the
ability to skip parsing of the local directory entries when you know you don't
need the extra field data of the local file header.
We do know the total size of the central directory as it is stored inside the
"End of central directory record" or "Zip64 end of central directory record".
Things might get faster if we read things in one go, but we'd probably want to
measure whether the difference is actually significant (and it would be a
different issue :) )
> Opening of a very large zip file is extremely slow compared to
> java.util.zip.ZipFile
>
>
> Key: COMPRESS-466
> URL: https://issues.apache.org/jira/browse/COMPRESS-466
> Project: Commons Compress
> Issue Type: Bug
> Components: Compressors
>Affects Versions: 1.18
> Environment: Tested both on Linux and OSX 10.13.6.
>Reporter: Jakob Sultan Ericsson
>Priority: Major
>
> We have a quite large zip file 35 gb and try to open this with ZipFile.
> {code:java}
> try (ZipFile zf = new ZipFile(new File("35gb.zip"))) {
> System.out.println("File opened..." + (System.currentTimeMillis()
> - start));
> }
> {code}
> This code takes about 300 000 - 400 000 ms (5-6 minutes).
> If I run this with JDK-builtin java.util.zip.ZipFile, same code takes 300 ms
> (less than a second).
> I'm not totally sure what it is the problem but I did some debugging and
> basically all time is spent in
> {code:java}
> private void resolveLocalFileHeaderData(final Map NameAndComment> entriesWithoutUTF8Flag)
> {code}
> Anything that can be done to improve this?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16641031#comment-16641031
]
Gilles commented on GEOMETRY-14:
{quote}The transform classes are used to transform both points and vectors
{quote}
What are the different use-cases?
Having had a quick look at {{Point3D}} and {{Vector3}}, they seem fairly
similar in their API and fairly convoluted in their inheritance hierarchy.
We may want to have a user guide explaining the design and how it is put to
use with concrete examples of when to use this vs that class/interface. It will
surely spare us puzzled faces later on.
When we wonder whether an {{AffineTransform3D}} _is-a_
{{UnaryOperator}} or {{UnaryOperator}}, there is some alarm
starting to ring...
{quote}Did you have any other alternatives in mind?
{quote}
In principle, there are two use-cases that arise from the above discussion:
# Expressing a sequence of {{AffineTransform3D}} operations
# Combining a sequence of {{AffineTransform3D}} operations
If the former is ever useful, then the {{UnaryOperator}} approach seems to
allow more flexibility in using the JDK API (stream, filter, ...).
If the second is necessary for performance reason, for example (IIUC) when the
same transform is to be applied to many points (or was it vectors? ;)), a
simpler (IMHO) API may be:
{code:java}
public static AffineTransform3D combine(AffineTransform3D ... transforms) {
AffineTransform3D c = identity();
for (int i = 0; i < transforms.length; i++) {
c = c.times(transforms[i]);
}
return c;
}
{code}
So perhaps, it is the right to setup "real-life" use-cases as you mentioned in
your roadmap post to the ML, in order to keep us in the right track (i.e.
trying to avoid API and performance mistakes).
Also, have you already looked at how e.g.
# existing classes such as {{Rotation}} fit with {{AffineTransform3D}}
# usage of {{Quaternion}} (from ["Commons
Numbers"|https://git1-us-west.apache.org/repos/asf?p=commons-numbers.git;a=blob;f=commons-numbers-quaternion/src/main/java/org/apache/commons/numbers/quaternion/Quaternion.java;h=86d7fdfa53d2b61bd07cebd05c02008f2809ebd9;hb=HEAD])
?
> AffineTransform?D Classes
> -
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> Pull Request #1: https://github.com/apache/commons-geometry/pull/14
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] commons-lang issue #367: Update event tests to JUnit Jupiter
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/367 Thanks! ð ---
[GitHub] commons-lang pull request #367: Update event tests to JUnit Jupiter
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/367 ---
