[jira] [Commented] (NUMBERS-90) DoublePrecisionContext
[
https://issues.apache.org/jira/browse/NUMBERS-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16753011#comment-16753011
]
Gilles commented on NUMBERS-90:
---
{quote}These classes are meant to replace the usage of tolerance values [...]
{quote}
I know, and I agree with the goal.
It's the design which IIUC I'm not satisfied with.
{quote}The logic is the same for any size of cubes.
{quote}
Is the "thickness" (*absolute* tolerance) the same for small coordinates as for
very large ones?
Unless I'm missing something, I don't think it should be for figuring out
whether two points are close.
> DoublePrecisionContext
> --
>
> Key: NUMBERS-90
> URL: https://issues.apache.org/jira/browse/NUMBERS-90
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Blocker
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> We should add a new class to commons-numbers-core that encapsulates
> configurable strategies for comparing doubles. This is required for
> GEOMETRY-11. Here is what I'm picturing:
> {code:java}
> // abstract class for the general concept of comparisons
> public abstract class DoublePrecisionContext implements Comparator {
> public abstract boolean equals(double a, double b);
> public int compare(double a, double b) { /* ... */ }
> public int compare(Double a, Double b) { /* ... */ }
> }
> // ...
> // concrete class implementing a specific strategy
> public class EpsilonUlpDoublePrecisionContext extends DoublePrecisionContext {
> public EpsilonUlpDoublePrecisionContext(double eps, double maxUlps) { /*
> ... */ }
> @Override
> public boolean equals(double a, double b) { /* ... */ }
> } {code}
> Pull request: https://github.com/apache/commons-numbers/pull/28
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEOMETRY-40) Replace commons-rng with commons-geometry on developers guide
Sven Rathgeber created GEOMETRY-40: -- Summary: Replace commons-rng with commons-geometry on developers guide Key: GEOMETRY-40 URL: https://issues.apache.org/jira/browse/GEOMETRY-40 Project: Apache Commons Geometry Issue Type: Task Reporter: Sven Rathgeber On the developer page: [https://commons.apache.org/proper/commons-geometry/developers.html] are several references to commons-rng. * [http://gitbox.apache.org/repos/asf/commons-rng.git] * [https://apach...@gitbox.apache.org/repos/asf/commons-rng.git] * [ Geometry Wish List Wiki Page.|http://wiki.apache.org/commons/RngWishList] * [ Commons Geometry Issue Tracking Page|http://commons.apache.org/rng/issue-tracking.html] They should be replace with references to commons-geometry. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (VFS-360) Add HTTP provider based on HttpComponents HttpClient 4
[ https://issues.apache.org/jira/browse/VFS-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated VFS-360: - Description: Migrate to HttpComponent HttpClient from the old Commons HttpClient. VFS URL prefix are "http4" and "http4s". The prefix "http" and "https" are still assigned to HttpClient version 3. We will switch "http" and "https" to HttpClient 4 at some point in the future; then we might reassign HttpClient version 3 to "http3" and "http3s" for this who mat need any behavior specific to HttpClient 3. Also forthcoming will be the use of HttpClient 5 which is currently in beta. was: Migrate to HttpComponent HttpClient from the old Commons HttpClient. > Add HTTP provider based on HttpComponents HttpClient 4 > -- > > Key: VFS-360 > URL: https://issues.apache.org/jira/browse/VFS-360 > Project: Commons VFS > Issue Type: Improvement >Reporter: Gary Gregory >Priority: Major > > Migrate to HttpComponent HttpClient from the old Commons HttpClient. > VFS URL prefix are "http4" and "http4s". The prefix "http" and "https" are > still assigned to HttpClient version 3. > We will switch "http" and "https" to HttpClient 4 at some point in the > future; then we might reassign HttpClient version 3 to "http3" and "http3s" > for this who mat need any behavior specific to HttpClient 3. > Also forthcoming will be the use of HttpClient 5 which is currently in beta. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16753114#comment-16753114
]
Otto Fowler commented on VFS-398:
-
Yeah, my Jira login pre-dates my apache id, I am in that list, but as
[o...@apache.org.|mailto:o...@apache.org.]
Who is on the PMC of commons who can give me rights in jira?
Once vfs is in git ( having gotten a couple of PRs landed ) I'll be more
comfortable doing commit then review.
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
> Fix For: 2.3
>
> Attachments: VFS-398-gg-00.patch
>
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision&revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file";);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (VFS-360) Add HTTP provider based on HttpComponents HttpClient 4
[ https://issues.apache.org/jira/browse/VFS-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved VFS-360. -- Resolution: Fixed Fix Version/s: 2.3 > Add HTTP provider based on HttpComponents HttpClient 4 > -- > > Key: VFS-360 > URL: https://issues.apache.org/jira/browse/VFS-360 > Project: Commons VFS > Issue Type: Improvement >Reporter: Gary Gregory >Priority: Major > Fix For: 2.3 > > > Migrate to HttpComponent HttpClient from the old Commons HttpClient. > VFS URL prefix are "http4" and "http4s". The prefix "http" and "https" are > still assigned to HttpClient version 3. > We will switch "http" and "https" to HttpClient 4 at some point in the > future; then we might reassign HttpClient version 3 to "http3" and "http3s" > for this who mat need any behavior specific to HttpClient 3. > Also forthcoming will be the use of HttpClient 5 which is currently in beta. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16753126#comment-16753126
]
Gary Gregory commented on VFS-398:
--
I was hoping I could but it is not a Jira thing I think. I think you need to be
in the proper LDAP group OR infra needs to give you Jira karma specifically.
Not 100% sure.
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
> Fix For: 2.3
>
> Attachments: VFS-398-gg-00.patch
>
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision&revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file";);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (COMMONSSITE-127) [release-plugin] ReadmeHtmlVelocityDelegate chops up artifactId too much to get to componentId
Rob Tompkins created COMMONSSITE-127:
Summary: [release-plugin] ReadmeHtmlVelocityDelegate chops up
artifactId too much to get to componentId
Key: COMMONSSITE-127
URL: https://issues.apache.org/jira/browse/COMMONSSITE-127
Project: Commons All
Issue Type: Improvement
Affects Versions: 1.5
Reporter: Rob Tompkins
Fix For: 1.6
Instead of parsing out the {{componentId}} from the {{artifactId}}, it is
likely simpler to add {{componentId}} to the builder such that we build
Delegate in the following fashion:
{code:java}
ReadmeHtmlVelocityDelegate delegate = ReadmeHtmlVelocityDelegate.builder()
.withArtifactId("commons-lang3")
.withComponentId("lang")
.withVersion("3.8.1")
.withSiteUrl("http://commons.apache.org/text";)
.build();
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16753130#comment-16753130
]
Otto Fowler commented on VFS-398:
-
A PMC member should be able to get into the project dashboard and assign users
to roles. I can do this with METRON as I am on the pmc
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
> Fix For: 2.3
>
> Attachments: VFS-398-gg-00.patch
>
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision&revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file";);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NUMBERS-90) DoublePrecisionContext
[
https://issues.apache.org/jira/browse/NUMBERS-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16753152#comment-16753152
]
Matt Juntunen commented on NUMBERS-90:
--
{quote}Is the "thickness" (*absolute* tolerance) the same for small coordinates
as for very large ones?
{quote}
It's set by the caller for each object. Normally, you would use the same value
for all of the objects that you're working with at the time to keep things
consistent. For example, you'd choose a relatively large epsilon if you expect
your coordinate value range to be large and a smaller one if you expect it to
be small.
{quote}Unless I'm missing something, I don't think it should be for figuring
out whether two points are close.
{quote}
Are there other options?
> DoublePrecisionContext
> --
>
> Key: NUMBERS-90
> URL: https://issues.apache.org/jira/browse/NUMBERS-90
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Blocker
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> We should add a new class to commons-numbers-core that encapsulates
> configurable strategies for comparing doubles. This is required for
> GEOMETRY-11. Here is what I'm picturing:
> {code:java}
> // abstract class for the general concept of comparisons
> public abstract class DoublePrecisionContext implements Comparator {
> public abstract boolean equals(double a, double b);
> public int compare(double a, double b) { /* ... */ }
> public int compare(Double a, Double b) { /* ... */ }
> }
> // ...
> // concrete class implementing a specific strategy
> public class EpsilonUlpDoublePrecisionContext extends DoublePrecisionContext {
> public EpsilonUlpDoublePrecisionContext(double eps, double maxUlps) { /*
> ... */ }
> @Override
> public boolean equals(double a, double b) { /* ... */ }
> } {code}
> Pull request: https://github.com/apache/commons-numbers/pull/28
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
