in concrete terms instead of
abstractions.
-Matt
From: Gilles <gil...@harfang.homelinux.org>
Sent: Monday, April 30, 2018 8:03 AM
To: dev@commons.apache.org
Subject: Re: [geometry] Points and Vectors Proposal
Hello.
On Sun, 29 Apr 2018 02:40:54 +, Matt Juntunen
Hi all,
I'm trying to add support for polar and spherical coordinates to the Euclidean
geometry code. My basic idea is to add them as simple DTOs with getters and
factory methods in the Point?D and Vector?D classes. For example:
Polar polar = Polar.of(1, Math.PI / 2);
polar.getRadius(); //
o: Commons Developers List
Subject: [Geometry] New Cartesian-centric API
Hello.
Matt Juntunen proposes to substantially modify the API of the
"geometry" code ported from "Commons Math".[1]
Since Matt is the sole currently visible contributor to this
functionality, I've just co
Euclidean Point/Vector Methods
On Sun, 24 Jun 2018 19:09:38 +, Matt Juntunen wrote:
> Hi all,
>
>
> I'd like to add some additional methods to the Euclidean Point/Vector
> classes. Some are for convenience/readability and some are critical
> pieces of functionality that I beli
Subject: Re: [geometry] Polar/Spherical Coordinates API
Hi.
On Sun, 24 Jun 2018 18:44:47 +, Matt Juntunen wrote:
> Hello,
>
>
> I didn't receive any feedback on this so I'm going to assume that
> everyone is okay with this approach.
More likely, nobody had a look. :-}
Hi all,
I'd like to add some additional methods to the Euclidean Point/Vector classes.
Some are for convenience/readability and some are critical pieces of
functionality that I believe are missing.
Vector Methods:
1. length() - Return the length of the vector; this is a more intuitive
intuitive. Likewise,
the properties for the PolarCoordinates class are "radius" and "azimuth" (there
was no prior version of this class).
Thanks,
Matt
From: Matt Juntunen
Sent: Monday, June 4, 2018 11:06 PM
To: Commons Developers Lis
essage.]
On Tue, 24 Apr 2018 01:31:43 +, Matt Juntunen wrote:
> Hi Gilles,
>
> The hierarchy would be wrong from a conceptual POV: A vector can be
> described by Cartesian coordinates, but it should be possible to
> introduce new coordinate systems (polar in 2D, spherical in 3D)
+ val.getY());
}
}
-Matt
From: Gilles <gil...@harfang.homelinux.org>
Sent: Saturday, April 28, 2018 7:28 AM
To: dev@commons.apache.org
Subject: Re: [geometry] Points and Vectors Proposal
Hi.
On Thu, 26 Apr 2018 21:19:08 +0000, Matt Juntunen wrote:
&
.
Thoughts? Comments? I have a project at work coming up near the end of the year
that I'd really love to use commons-geometry on, so that's what I'm aiming for
in terms of a timeline.
Thanks,
Matt Juntunen
gil...@harfang.homelinux.org>
Sent: Thursday, April 12, 2018 9:12 AM
To: dev@commons.apache.org
Subject: Re: [geometry] Initial Project Structure
Hi Matt.
On Sun, 8 Apr 2018 02:40:26 +, Matt Juntunen wrote:
> Hi all,
>
> I'm forwarding a conversation I had with Gilles on the project
> structure f
spaces, such as spherical, and other special-purpose code that we have yet to
develop.
Thoughts?
Thanks,
Matt Juntunen
From: Gilles <gil...@harfang.homelinux.org>
Sent: Saturday, April 7, 2018 6:39 PM
To: Matt Juntunen
Subject: Re: Commons Geometry P
46:40 -0400, Rob Tompkins wrote:
>> On Apr 14, 2018, at 9:00 AM, Gilles <gil...@harfang.homelinux.org>
>> wrote:
>>
>> Hello.
>>
>> On Sat, 14 Apr 2018 04:24:35 +, Matt Juntunen wrote:
>>> Hi Gilles,
>>>
>>> That's actually really close to
artesian3D p, final Cartesian3D normal, final double
tolerance)
With my proposed changes, it would look like this:
public Plane(final Point3D p, final Vector3D normal, final double tolerance)
The code is easier to read and the compiler will also help prevent algorithm
errors.
Thoughts?
R
gt; with the environment (maven, git, Jenkins, Travis).
> Hence this part will be out of the way if/when tackling
> "Commons Statistics" and its design issues.
>
> Matt Juntunen,
> Ready to dr
Hi all,
Gilles and I are stuck on a discussion of a few of the names in the API for the
Euclidean vector classes (Vector1D, Vector2D, Vector3D) and I'd like to get
some outside feedback. Our discussion has focused on ease of use, clarity, and
mathematical accuracy. Below are a few of the
: Gilles
Sent: Saturday, December 15, 2018 9:52 AM
To: dev@commons.apache.org
Subject: Re: [geometry] 1.0 Roadmap
Hi.
On Fri, 7 Sep 2018 02:29:21 +, Matt Juntunen wrote:
> Hi all,
>
> I've been working on the new commons-geometry component for a while
> now and I wanted to share w
Hi guys,
FYI, I've been working on a quaternion-related class named QuaternionRotation
for commons-geometry (see link below). It includes slerp as well as several
other geometry-oriented methods, such as conversion to/from axis-angle
representations and creation from basis rotations. It's not
1 Dec 2018 06:05:31 +, Matt Juntunen wrote:
>> Hi guys,
>>
>> FYI, I've been working on a quaternion-related class named
>> QuaternionRotation for commons-geometry (see link below). It
>> includes
>> slerp as well as several other geometry-oriented methods, s
/apache/commons/geometry/euclidean/threed/rotation/QuaternionRotation.java.
-Matt
From: Gilles
Sent: Sunday, December 2, 2018 3:57 PM
To: dev@commons.apache.org
Subject: Re: [Numbers][Geometry] Where to define "quaternion" (Was: Making
Quaternion a VA
June 2019, 11:54:01 pm NZST, Matt Juntunen
wrote:
Hi all,
I've been working on GEOMETRY-32 for the past several months and I've come to
the point where I could really use some help and/or another pair of eyes on the
code to get it wrapped up. The issue involves refactoring the original binary
Hi all,
I've been working on GEOMETRY-32 for the past several months and I've come to
the point where I could really use some help and/or another pair of eyes on the
code to get it wrapped up. The issue involves refactoring the original binary
space partitioning (BSP) tree code from
Hi Sven,
Until we can roll out an actual release of numbers and geometry, I think your
best bet is to fork commons-geometry and all of its SNAPSHOT dependencies,
change the groupIds and/or artifactIds in the poms to something custom (to
avoid conflicts later on), and then release those
mai 2019 à 15:37, Rob Tompkins a écrit :
>>
>>
>>> On May 23, 2019, at 7:25 AM, Gilles Sadowski wrote:
>>>
>>> Hi.
>>>
>>>> Le mer. 22 mai 2019 à 14:07, Matt Juntunen a
>>>> écrit :
>>>>
>>&g
Hi Bajit,
Thanks for your input. Can you please provide some examples of what you mean
here? Why exactly should it be removed and how would that improve the API? The
Point interface is the central interface of the geometry code and allows us to
write algorithms that work across multiple spaces
Hi all,
I've been working on the BSP tree refactor and general API cleanup for a while
now and I finally have the core and Euclidean classes complete. I have the code
in a draft PR on github [1] and I'm hoping to get as much feedback on it as I
can. Everything is in its final state from my
dowski
Sent: Saturday, August 17, 2019 6:00 PM
To: Commons Developers List
Subject: Re: [geometry] GEOMTRY-32 Feedback Requested
Hello.
Le sam. 17 août 2019 à 04:58, Matt Juntunen
a écrit :
>
> Hi Gilles,
>
> 1. I just rebased from master so hopefully that fixed the repo weirdness.
It
}
From: Gilles Sadowski
Sent: Friday, August 16, 2019 11:37 AM
To: Commons Developers List
Subject: Re: [geometry] GEOMTRY-32 Feedback Requested
Hello Matt.
Thanks for continuing to work on this.
Le jeu. 15 août 2019 à 17:56, Matt Juntunen
a écrit :
>
>
2019 à 05:14, Matt Juntunen
a écrit :
>
> Hi Gilles,
>
> I did intend on adding more convenience methods for generating standard
> shapes but I definitely think we should abstract it like you're suggesting.
> Your design got me thinking and I believe we could take the idea of a
Subject: Re: [geometry] GEOMTRY-32 Feedback Requested
Hi.
Le mer. 21 août 2019 à 04:42, Matt Juntunen
a écrit :
>
> Gilles,
>
> ConvexSubPlane is the main class representing 3D facets. There are
> convenience methods in the RegionBSPTree3D.Builder class for adding facets
> dire
Hi all,
I'm attempting to wrap up the refactoring work I've been doing with GEOMETRY-32
but I've hit a snag with the code for computing barycenters in 2D spherical
space. The results I'm getting seem mostly reasonable but they aren't as
consistent as I'd like, which makes me wonder if I'm
: [geometry] Spherical Barycenters
Hello.
Le ven. 15 nov. 2019 à 15:34, Matt Juntunen
a écrit :
>
> Hi all,
>
> I'm attempting to wrap up the refactoring work I've been doing with
> GEOMETRY-32 but I've hit a snag with the code for computing barycenters in 2D
> spherical space. The r
From: Gilles Sadowski
Sent: Tuesday, December 3, 2019 11:42 AM
To: Commons Developers List
Subject: Re: [Geometry] Exceptions hierarchy
Hello.
2019-12-03 17:13 UTC+01:00, Matt Juntunen :
> Hello,
>
> I don't feel like ArithmeticException quite captures all of the possible
&
I just added a number of new issues to JIRA. The ones that I would consider
required for a 1.0 release are:
-GEOMETRY-67 - OutlineExtractor
-GEOMETRY-68 - Raycast/Linecast API
-GEOMETRY-69 - BSPTreeVisitor stop visit
-GEOMETRY-72 - Boundary API
-GEOMETRY-77 - BoundsXD classes
-GEOMETRY-73 -
Hello,
I don't feel like ArithmeticException quite captures all of the possible
geometry exception states. For example, it seems odd to me to throw an
ArithmeticException when a plane cannot be constructed due to a given set of
points being collinear [1]. That idea feels beyond the concept of
?
Hi Matt.
Le mar. 3 déc. 2019 à 18:37, Matt Juntunen a écrit :
>
> I just added a number of new issues to JIRA. The ones that I would consider
> required for a 1.0 release are:
>
> -GEOMETRY-67 - OutlineExtractor
> -GEOMETRY-68 - Raycast/Linecast API
> -GEOMETRY-69 - BSPT
Hello,
I'm looking into NUMBERS-40, which suggests that the exception behavior of
commons-numbers (specifically the gamma package) needs to be made more
consistent. Below is a summary of the public exception types explicitly thrown
by each module.
arrays
IndexOutOfBoundsException
Any word on this?
-Matt
From: Gilles Sadowski
Sent: Wednesday, January 15, 2020 10:47 AM
To: Commons Developers List
Subject: [All] Sonarcloud reports zero coverage
Hello.
"Sonar" reports are created for several projects, a.o.
Hello,
Any chance we can get a release (beta or full) for commons-numbers? As I
mentioned in another thread, commons-geometry is ready for a beta release but
we need commons-numbers to be released before we can do that.
Regards,
Matt J
Hello,
If no one has any objections to the current exception usage in commons-numbers,
I suggest we close NUMBERS-40. This would allow us to continue with the beta
release (as mentioned in another thread).
-Matt
From: Matt Juntunen
Sent: Sunday, January 26
tps://github.com/apache/commons-numbers/pull/6
From: Gilles Sadowski
Sent: Thursday, January 23, 2020 11:11 AM
To: Commons Developers List
Subject: Re: [numbers] Release?
Hi.
Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
a écrit :
>
> Hello,
>
> An
Hi Alex,
Thanks for the updates on this. FYI, the current geometry build fails due to a
missing import:
https://travis-ci.org/apache/commons-geometry/jobs/651768129#L3806.
-Matt
From: Alex Herbert
Sent: Monday, February 17, 2020 7:18 PM
To: Commons Developers
Developers List
Subject: Re: [numbers] Release?
Hi.
Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
a écrit :
>
> Hello,
>
> Any chance we can get a release (beta or full) for commons-numbers?
Non-exhaustive check-list is here:
https://issues.apache.org/jira/browse/NUMBERS-25
Are we waiting on anything for a numbers release?
-Matt
From: Matt Juntunen
Sent: Monday, February 17, 2020 10:36 PM
To: Commons Developers List
Subject: Re: [numbers] Release?
Gilles,
> Anyways, +1 to making beta releases, even while still work
om: Gilles Sadowski
> Sent: Thursday, January 23, 2020 11:11 AM
> To: Commons Developers List
> Subject: Re: [numbers] Release?
>
> Hi.
>
> Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
> a écrit :
>>
>> Hello,
>>
>> Any chance we can get a release
rom: Gilles Sadowski
Sent: Wednesday, January 8, 2020 8:16 AM
To: Commons Developers List
Subject: Re: [geometry] Rename Transform to AffineTransform
Hi.
Le mer. 8 janv. 2020 à 04:39, Matt Juntunen
a écrit :
>
> Gilles,
>
> > I thought that the question was how to replace "transform&
changed.
-Matt
From: Gilles Sadowski
Sent: Saturday, January 18, 2020 1:40 PM
To: Commons Developers List
Subject: Re: [geometry] Rename Transform to AffineTransform
Hello.
2020-01-18 15:40 UTC+01:00, Matt Juntunen :
> Gilles,
>
>> If the "Transform&quo
__
From: Gilles Sadowski
Sent: Monday, January 13, 2020 8:03 PM
To: Commons Developers List
Subject: Re: [geometry] Rename Transform to AffineTransform
Hi.
Le lun. 13 janv. 2020 à 04:39, Matt Juntunen
a écrit :
>
> Gilles,
>
> > How about keeping "Transform" for
d as:
> ---CUT---
> In Euclidean space, this must be an affine transform.
> ---CUT---
That's part of what the documentation now says.
-Matt
From: Gilles Sadowski
Sent: Monday, January 20, 2020 2:28 PM
To: Commons Developers List
Subject: Re: [geometry] Rename T
;preservesOrientation". Good point on the protected methods,
though. I've moved them into the internal "Matrices" utility class.
-Matt
From: Gilles Sadowski
Sent: Sunday, January 19, 2020 9:06 AM
To: Commons Developers List
Subject: Re: [geometry] Rename Transform to AffineT
e most
complete and mathematically accurate.
-Matt
From: Gilles Sadowski
Sent: Monday, January 20, 2020 8:52 AM
To: Commons Developers List
Subject: Re: [geometry] Rename Transform to AffineTransform
Hello.
2020-01-20 14:28 UTC+01:00, Matt Juntunen :
> Gilles,
>
>> I
Hello,
I think that commons-geometry is ready for a beta release, as discussed
previously. If there are no objections, how do we make that happen?
Regards,
Matt J
Hello.
Le mar. 21 janv. 2020 à 14:41, Matt Juntunen
a écrit :
>
> Hello,
>
> I think that commons-geometry is ready for a beta release, as discussed
> previously. If there are no objections, how do we make that happen?
Note that "Numbers" should be released fir
Gilles,
Yes, users are responsible for handling their own PrecisionContexts. The idea
behind the Equivalency interface was to provide an easy way to perform "fuzzy"
comparisons between objects. The interface itself does not define what the
comparison involves. Classes that implement the
8:12 PM
To: Commons Developers List
Subject: Re: [Geometry] Class "Equivalency"
Hi.
2020-01-03 22:02 UTC+01:00, Matt Juntunen :
> Gilles,
>
> Yes, users are responsible for handling their own PrecisionContexts. The
> idea behind the Equivalency interface was to provide an easy wa
ot;eq" be an overload of "equals" would to me imply
that they have the same general properties, which is not the case.
-Matt
From: Gilles Sadowski
Sent: Saturday, January 4, 2020 6:26 AM
To: Commons Developers List
Subject: Re: [Geometry] Class &
message -
De : Gilles Sadowski
Date: sam. 4 janv. 2020 à 19:54
Subject: Re: [Geometry] Class "Equivalency"
To: Matt Juntunen
Hello.
Le sam. 4 janv. 2020 à 17:30, Matt Juntunen
a écrit :
>
> Gilles,
>
> I removed the Equivalency interface and pushed the changes to
Hi all,
The documentation for the o.a.c.geometry.core.Transform interface (which comes
from the original commons-math version) states that implementations must be
affine. Therefore, I think we should rename this interface to AffineTransform
to avoid confusion with other types of transforms,
h"?
Indirectly. SphericalPolygonsSet extended AbstractRegion, which included an
applyTransform(Transform) method.
-Matt
From: Gilles Sadowski
Sent: Tuesday, January 7, 2020 10:29 AM
To: Commons Developers List
Subject: Re: [geometry] Rename Transform to Af
Subject: Re: [geometry] Rename Transform to AffineTransform
Le mar. 7 janv. 2020 à 17:55, Matt Juntunen
a écrit :
>
> Gilles,
>
> > "AffineMap" (?)
>
> I think any name that doesn't include the word "transform" somehow would
> probably be confusin
Hi Gary,
The commons-geometry JIRA project may be misconfigured since it seems as though
committers don't automatically have permission to resolve issues. (See the
discussion on GEOMETRY-56.) Are you able to look into this?
Thanks,
Matt J
Follow-up: I personally have admin privileges thanks to Alex[1]. There still
seems to be an underlying issue but we may have all of the privileges we need
for now.
-Matt
[1] https://issues.apache.org/jira/browse/INFRA-19956
From: Matt Juntunen
Sent: Thursday
Hello all,
I'm creating a dist-archive module for commons-geometry using commons-rng as a
template [1]. However, when I build the project it fails with an errors saying
that the url https://dist.apache.org/repos/dist/dev/commons/geometry does not
exist, which is indeed the case. Browsing that
x Herbert <mailto:alex.d.herb...@gmail.com>> a écrit :
>>
>>
>>
>>> On 22 Feb 2020, at 00:29, Gilles Sadowski wrote:
>>>
>>> Hi.
>>>
>>> Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
>>> a écrit :
>>>>
distribution svn url
On 2020-03-08, Matt Juntunen wrote:
> I'm creating a dist-archive module for commons-geometry using
> commons-rng as a template [1]. However, when I build the project it
> fails with an errors saying that the url
> https://dist.apache.org/repos/dist/dev/commons/geometry d
url
On 2020-03-08, Matt Juntunen wrote:
> I don't currently have permissions for that. Is someone able to create
> "geometry" and "numbers" directories in there?
Done.
But I suspect you won't have permission to upload a distribu
Thank you! It's a great honor.
-Matt
From: Rob Tompkins
Sent: Tuesday, March 10, 2020 9:02 AM
To: Commons Developers List
Subject: Re: [ANNOUNCE] Welcome Matt Juntunen to Apache Commons
Congrats Matt! Welcome aboard.
-Rob
> On Mar 10, 2020, at 8:46 AM, G
h=e671acf555e31564cc2049467014ab4f873a48e7;hb=HEAD
>
> -Matt
>
> From: Gilles Sadowski
> Sent: Tuesday, April 7, 2020 12:32 PM
> To: Commons Developers List
> Subject: Re: [Geometry][Math] Equivalent of CM's "RotationConvention&qu
Hi Gilles,
I like that idea. I'm picturing that as something that could happen after the
first beta release. Here is my current roadmap (of sorts):
1. Wrap up a few issues (GEOMETRY-92, 93, and 94)
2. Release 1.0-beta1
3. Add model-specific example code as you have started with the
Hello.
I just submitted a PR with some large API changes in the subhyperplane classes
and I'd like to see if anyone has any feedback. The PR is here:
https://github.com/apache/commons-geometry/pull/75. The changes are detailed in
the issues GEOMETRY-92 and GEOMETRY-93 but, in short, they make
Subject: Re: [Geometry][Math] Equivalent of CM's "RotationConvention"
Hello.
Le mar. 7 avr. 2020 à 03:18, Matt Juntunen a écrit :
>
> Hi Gilles,
>
> I removed the RotationConvention enum from commons-geometry because it was
> more confusing than useful. Instead, I s
-beta1
org.apache.commons
commons-numbers-rootfinder
1.0-beta1
Matt Juntunen,
on behalf of the Apache Commons Team
Hi all,
I just completed the commons-numbers 1.0-beta1 release and I have a couple of
follow-up notes:
* I was unable to add the release using the form at
https://reporter.apache.org/addrelease.html?commons. I received an error
message saying that I was not part of the PMC or an ASF
Hi Gilles,
I removed the RotationConvention enum from commons-geometry because it was more
confusing than useful. Instead, I specified [1] that commons-geometry uses
"active rotations" by convention (equivalent to
RotationConvention.VECTOR_OPERATOR). If users want to use the equivalent of
e complete for the 1.0-beta1 release
(there are currently 5).
-Matt
From: Gilles Sadowski
Sent: Sunday, April 19, 2020 11:22 AM
To: Commons Developers List
Subject: Re: [Geometry] CSG?
Hello.
Le sam. 18 avr. 2020 à 05:01, Matt Juntunen
a écrit :
>
> Hi Gi
I find them useful. We often use old versions in my day job and these links are
the quickest and easiest way to get to the docs.
-Matt
From: Gary Gregory
Sent: Monday, April 20, 2020 9:50 AM
To: Commons Developers List
Subject: [IO] and Javadoc library
+1 for removing.
-Matt
From: Gilles Sadowski
Sent: Thursday, April 9, 2020 4:52 AM
To: dev@commons.apache.org
Subject: [Math][Geometry] Ditch reliquate of "geometry" package in CM?
Hello.
This is a possible outcome of the discussion in another thread.[1]
I agree. Let's remove it.
-Matt
From: Gilles Sadowski
Sent: Thursday, April 9, 2020 5:30 AM
To: Commons Developers List
Subject: Re: [Geometry][Math] Equivalent of CM's "RotationConvention"
Hi.
2020-04-09 3:30 UTC+02:00, Matt Juntunen :
> I
It looks like the issue is related to the dist-archive module. A while ago, I
used the approach from commons-rng and included the dist-archive module under
the "release" profile. However, the dist-archive build requires "mvn site" to
be run before or as part of the build (as indicated in the
This VOTE passes with the following +1 binding votes:
* Gilles Sadowski
* Bruno Kinoshita
* Alex Herbert
I will proceed with the release and send the announcement 24 hours after it is
complete.
Thank you all,
Matt J
g the actual release candidate in case
anyone has any objections.
Alex, I see you made some more commits to master (updating LICENSE and NOTICE
file names and some changes to Complex). Should I pull those into the release?
Regards,
Matt
____
From: Matt Juntunen
Sen
Thanks everyone for the information. I'll start working toward this and send
out an email when I'm ready to start cutting the release.
One thing I notice is that there isn't a commons-numbers user guide to speak
of. Is this something that needs to be added before the beta release?
-Matt
OK, but really should fix...
[ ] -1 I oppose this release because...
Thank you,
Matt Juntunen,
Release Manager (using key 7DD53AEFEDF1C3D392B51EBE346F4FCECFB70B1A)
For following is intended as a helper and refresher for reviewers.
Validating a release candidate
=
, April 3, 2020 5:45 PM
To: Commons Developers List
Subject: Re: [VOTE] Release Apache Commons Numbers (full distribution)
1.0-beta1 based on RC1
Hi.
Le ven. 3 avr. 2020 à 17:25, Matt Juntunen a écrit :
>
> We have been working hard to prepare Apache Commons Numbers for an initial
> re
ts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1497/org/apache/commons/commons-numbers/1.0-beta1/
Cheers
Bruno
On Saturday, 4 April 2020, 4:25:26 am NZDT, Matt Juntunen
wrote:
We have been working hard to prepare Apache Commons Numbers fo
Hello,
I just submitted a PR [1] with changes related to shape generation. I'd be
interested if anyone has feedback. The primary changes I made are
1. adding Circle and Sphere classes,
2. changing the Parallelogram and Parallelepiped from utility classes to
subclasses of ConvexArea and
Hello,
I propose releasing commons-numbers 1.0-B1. I will serve as the release
manager. Here are a few notes on the release:
* This will be a beta release. No guarantees are made for stability or
compatibility with future releases.
* The package coordinates for the project will not be
Hi all,
After reading all of the comments, here is what I propose for moving forward:
* Use version number "1.0-beta1" instead of "1.0-B1". (Gary, were you
planning on updating the versioning guidelines?)
* Create a new release branch named "1.0-beta1-release" from the
"1.0-B1-release"
; >> Hi.
> >>
> >> Le lun. 30 mars 2020 à 16:19, Matt Juntunen
> >> a écrit :
> >>> The issue I saw with the site [1] was that the text under the Releases
> >>> section says "There is no offcial release yet. Come and join deve
The issue I saw with the site [1] was that the text under the Releases section
says "There is no offcial release yet. Come and join development work!"
Clearly, that won't work for a release version.
Also, the Nexus staging repository (1496) failed validation because it could
not find my key in
+1 for "beta".
-Matt
From: Rob Tompkins
Sent: Monday, March 30, 2020 10:25 AM
To: Commons Developers List
Subject: Re: [poll] Beta versions should be labeled "Beta", not "B".
I’m a +1 on “beta" over “B"
It is indeed a good idea.
> On Mar 30, 2020, at 10:14
That is interesting. I've never run into this. There are explicit suppressions
for those checks in src/main/resources/checkstyle/checkstyle-suppressions.xml.
Do you have any more details? What mvn command are you running?
-Matt
From: Gary Gregory
Sent: Monday,
AM
To: Commons Developers List
Subject: Re: [numbers] 1.0-B1 Release Proposal
> On 29 Mar 2020, at 12:17, Matt Juntunen wrote:
>
> Hello,
>
> I propose releasing commons-numbers 1.0-B1. I will serve as the release
> manager. Here are a few notes on the release:
>
>
&g
ing due to Checstyle violations
On Mon, Mar 30, 2020 at 3:37 PM Matt Juntunen
wrote:
> That is interesting. I've never run into this. There are explicit
> suppressions for those checks in
> src/main/resources/checkstyle/checkstyle-suppressions.xml. Do you have any
> more details? What mvn co
I got it set up faster than I thought. I pushed a fix to master and I'll pull
it into the next RC. Let me know if it works for you or not.
-Matt
From: Matt Juntunen
Sent: Monday, March 30, 2020 4:23 PM
To: Commons Developers List
Subject: Re: [Numbers] Local
Hello,
Gilles and I have been working on polishing the API for commons-geometry and
wrapping up a couple of last issues before the 1.0-beta1 release. We've been
discussing the API design for some of the core classes in GEOMETRY-92 and
GEOMETRY-94 and I'd like to get some feedback from the
Hello,
I've created GEOMETRY-97 [1] to change commons-geometry to use the term
"centroid" to refer to the center of mass of a geometric object instead of the
term "barycenter" (inherited from commons-math). The two terms can be used
interchangeably [2] but "centroid" seems to be used far more
been changed. The
changes were made in commit eee258978cae8fe4987c2155ddfbd08c73d3c9db. Almost to
the beta release...
Regards,
Matt
From: Matt Juntunen
Sent: Friday, April 24, 2020 10:01 PM
To: Commons Developers List
Subject: [geometry] API Design Feedback
Hello
Hello,
Am I able to perform this beta release of numbers now that I am a committer? If
so, how would I go about it?
Thanks,
Matt
From: Matt Juntunen
Sent: Saturday, March 7, 2020 7:37 AM
To: Alex Herbert ; Commons Developers List
Subject: Re: [numbers
Hi Bajit,
My plan is to get a release of commons-geometry out as soon as possible,
although I have been saying this for more than a year at this point:-) However,
I actually believe we are very close now. There are only a few remaining issues
for the beta1 release and I currently have branches
1 - 100 of 262 matches
Mail list logo
