Re: (commons-geometry) branch master updated: GEOMETRY-110: add ConvexHull3D using Quickhull algorithm

[Matt Juntunen]

I apologize for that. I merged this through the GitHub UI (and will likely
never do so again). We can amend the message to remove all of the noise but
that would involve using `git push --force`, which is not something I've
ever done with an Apache repo.
-Matt

On Sat, Apr 27, 2024 at 8:42 PM Gilles Sadowski 
wrote:

> Hi.
>
> Although the list of successive changes might have been meaningful in
> separate
> commits, it seems like noise in a single one (e.g. many of them signal a
> change
> wrt to some previous state whose trace has been lost).  Obviously,
> repeating
> "GEOMETRY-110" serves no purpose.
> If possible (?), it would be neat to amend the log to just keep the first
> line.
>
> Regards,
> Gilles
>
> Le dim. 28 avr. 2024 à 02:14,  a écrit :
> >
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > mattjuntunen pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/commons-geometry.git
> >
> >
> > The following commit(s) were added to refs/heads/master by this push:
> >  new 2f4e86b7 GEOMETRY-110: add ConvexHull3D using Quickhull
> algorithm
> > 2f4e86b7 is described below
> >
> > commit 2f4e86b792693d4c2c0e5fb2c4f198541e1fecb6
> > Author: Andreas Goß <75903169+agos...@users.noreply.github.com>
> > AuthorDate: Sun Apr 28 02:14:00 2024 +0200
> >
> > GEOMETRY-110: add ConvexHull3D using Quickhull algorithm
> >
> > * GEOMETRY-110
> >
> > Add ConvexHull3D class and tests.
> >
> > * GEOMETRY-110
> >
> > Return only an unmodifiable collection of facets.
> >
> > * GEOMETRY-110
> >
> > Test for a large number of points.
> >
> > * Checkstyle Fix.
> >
> > * GEOMETRY-110
> >
> > Points are added to candidates again instead of a new point set.
> >
> > * GEOMETRY-110
> >
> > Only candidates points are distributed.
> >
> > * GEOMETRY-110
> >
> > Add Simplex type
> >
> > * GEOMETRY-110
> >
> > Create simplex while appending and cache it for later.
> >
> > * GEOMETRY-110
> >
> > Build simplex incrementially while appending points.
> >
> > * GEOMETRY-110
> >
> > Return facets as list and filter out duplicates in vertices.
> >
> > * GEOMETRY-110
> >
> > Returned collections have to be unmodifiable in public methods.
> >
> > * GEOMETRY-110
> >
> > Rename method and calculate maximum in a loop.
> >
> > * GEOMETRY-110
> >
> > Declare variable outside of loop.
> >
> > * GEOMETRY-110
> >
> > Rename methods.
> >
> > * GEOMETRY-110
> >
> > Replace bounds by array.
> >
> > * GEOMETRY-110
> >
> > Add check for appending a collection of points
> >
> > * [GEOMETRY-110]
> >
> > Delete hasOusidePoints and add exclusion for facets to spotbugs.
> >
> > * [GEOMETRY-110]
> >
> > Move isInside method into Facet class and reverse and rename it to
> isOutside
> >
> > * [GEOMETRY-110]
> >
> > Replace vertexToFacetMap with edgeMap
> >
> > * [Geometry-110]
> >
> > Change loop for creating edges.
> >
> > * [GEOMETRY-110]
> >
> > Facets are all located through edge operations. The edges are
> oriented in such a way, that neighbors share an edge in inverse orientation.
> >
> > * [GEOMETRY-110]
> >
> > Delete unnecessary debug code.
> >
> > * [GEOMETRY-110]
> >
> > Edges are oriented and lookup is done via an edgeMap. Each oriented
> edge is unique in association with a facet. Each facet stores the maximum
> offset and the associated point of outside points.
> >
> > * [GEOMETRY-110]
> >
> > - Rename Edge fields.
> > - Improve testing and assert all outputs of the algorithm.
> >
> > * [GEOMETRY-110]
> >
> > Check isDegenerate for all non-degenerate hulls.
> >
> > * [GEOMETRY-110]
> >
> > Even though the defined region is the same the number of facets can
> vary depending on the execution order of the algorithm.
> >
> > -
> >
> > Co-authored-by: agoß 
> > Co-authored-by: Andreas Goss 
> > ---
> >  .../euclidean/threed/hull/ConvexHull3D.java| 728
> +
> >  .../euclidean/threed/hull/package-info.java|  25 +
> >  .../euclidean/threed/hull/ConvexHull3DTest.java| 276 
> >  .../resources/spotbugs/spotbugs-exclude-filter.xml |   5 +
> >  4 files changed, 1034 insertions(+)
> >
> > [...]
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [GEOMETRY] Quickhull Implementation

[Matt Juntunen]

Hello!

Andreas, thank you for your contribution! It's good to see some work going
into commons-geometry since I've had to step away recently. Gilles is right
in that we didn't include the hull module in the 1.0 release because I felt
like it still needed work. What I'd like to do is remove that module
completely and pull the convex hull generation directly into the euclidean
module and hide the implementation algorithm details (as discussed in
GEOMETRY-144). I've replied to your comment on that Jira issue and I hope
to take a detailed look at your code over this weekend, if not before. If
you're interested in seeing the API I was aiming for when working on this,
my unfinished code is languishing on Github [1].

Regards,
Matt J

[1]
https://github.com/darkma773r/commons-geometry/blob/quickhull/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/threed/ConvexHull3D.java




On Mon, Jan 30, 2023 at 2:38 AM Andreas Goss 
wrote:

> Thanks for the quick reply. I need to create an Jira account first for
> that. I requested an account by writing to priv...@commons.apache.org
>
> Kind Regards
> Andreas
>
> Gilles Sadowski  schrieb am Mo. 30. Jan. 2023 um
> 00:11:
>
> > Hello.
> >
> > Le dim. 29 janv. 2023 à 19:25, Andreas Goss
> >  a écrit :
> > >
> > > Hello,
> > >
> > > I want to contribute a solution for the open Jira task GEOMETRY-110 (
> > >
> >
> https://issues.apache.org/jira/projects/GEOMETRY/issues/GEOMETRY-110?filter=allopenissues
> > ).
> > > I tried my best to organize the code according to guidelines and at
> least
> > > the maven build was succesful. I created a pull-request for the github
> > > clone. If someone could give me a code review and point out areas to
> > > improve the code or errors i would be very thankful.
> >
> > Thank you for tackling this issue.
> > It was part of a broader discussion about the API around the hull
> > functionality.
> > IIRC, the "commons-geometry-hull" module was not included in the first
> > release of "Commons Geometry" because Matt Juntunen was convinced
> > that a few enhancements were necessary.  Hopefully, he'll chime in order
> to
> > make this recollection more precise.
> >
> > A general question is whether we want to expose (make "public") classes
> > that implement the algorithm(s), such as "QuickHull3D".  For example, we
> > could perhaps have (untested and required comments missing...):
> > ---CUT---
> > public interface ConvexHull3D extends ConvexHull {
> >
> > public enum Generate {
> > QUICK_HULL((c, p) -> new QuickHull3D(p).generate(c));
> >
> > private final BiFunction,
> > DoubleEquivalence, ConvexHull3D> generator;
> >
> > private HullGenerator3D(BiFunction,
> > DoubleEquivalence, ConvexHull3D> generator) {
> > this.generator = generator;
> > }
> >
> > public ConvexHull3D from(Collection points,
> > DoubleEquivalence equivalence) {
> > return generator.apply(points, equivalence));
> > }
> > }
> >
> > public Collection getFacets();
> > }
> >
> > private class QuickHull3D {
> > private final DoubleEquivalence precision;
> >
> > QuickHull3D(DoubleEquivalence precision) {
> > this.precision = precision;
> > }
> >
> > ConvexHull3D generate(Collection points) {
> > // ...
> > return new SimpleConvexHull3D(...);
> > }
> > }
> >
> > private class SimpleConvexHull3D implements ConvexHull3D {
> > private final List vertices;
> > private final ConvexVolume region;
> > private Collection facets;
> >
> > SimpleConvexHull3D(...) {
> > // ...
> > }
> >
> > // ...
> > }
> > ---CUT---
> >
> > For other concrete (basic) remarks about the code, we can certainly
> > continue the conversation in comments on the JIRA report.
> >
> > Best regards,
> > Gilles
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: Re: Re: [fileupload] Have a FileUpload release (after 3.5 years)

[Matt Juntunen]

> we are volunteers, each with our own priorities and time limitations ;-)

Speaking of which...

I've had some major life changes occur recently and will not be able
to push this through. If anyone else is able to pick this up, that
would be appreciated.

Regards,
Matt J

On Thu, Jul 21, 2022 at 8:14 AM Gary Gregory  wrote:
>
> On Thu, Jul 21, 2022 at 7:54 AM Eric Bresie  wrote:
> >
> > Does any of this help?
> > (1) https://commons.apache.org/releases/index.html
> > (2) https://infra.apache.org/release-publishing.html
>
> We know how to release our software ;-) but, we are volunteers, each
> with our own priorities and time limitations ;-)
>
> Gary
> >
> > Eric Bresie
> > ebre...@gmail.com (mailto:ebre...@gmail.com)
> >
> > > On July 17, 2022 at 2:59:26 PM CDT, Gary Gregory  > > (mailto:garydgreg...@gmail.com)> wrote:
> > > Yeah, there is code that looks odd for 2022, like a custom Closeable
> > > interface instead of reusing the JRE's. I'll take a look.
> > >
> > > Gary
> > >
> > > On Sun, Jul 17, 2022 at 2:32 PM Matt Juntunen  > > (mailto:matt.a.juntu...@gmail.com)> wrote:
> > > >
> > > > Sounds good. Do you know of anything else that needs to be done? I'm
> > > > guessing we can hold off on a full 1.x migration guide until the full
> > > > 2.0.0 version.
> > > >
> > > > -Matt J
> > > >
> > > > On Sun, Jul 17, 2022 at 2:13 PM Gary Gregory  > > > (mailto:garydgreg...@gmail.com)> wrote:
> > > > >
> > > > > We should at least remove deprecated elements.
> > > > >
> > > > > Gary
> > > > >
> > > > > On Sun, Jul 17, 2022 at 10:49 AM Matt Juntunen
> > > > > mailto:matt.a.juntu...@gmail.com)> wrote:
> > > > > >
> > > > > > I am going to put the 2.0.0-beta1 release on my TODO list. I am
> > > > > > currently working toward a release of commons-text, so I can't be 
> > > > > > sure
> > > > > > on a timeline. If anyone has questions or time to pick this up, 
> > > > > > please
> > > > > > let me know.
> > > > > >
> > > > > > Regards,
> > > > > > Matt J
> > > > > >
> > > > > > On Fri, Jul 15, 2022 at 12:35 PM Matt Juntunen
> > > > > > mailto:matt.a.juntu...@gmail.com)> 
> > > > > > wrote:
> > > > > > >
> > > > > > > It sounds like we've agreed on creating a 2.0.0-beta1 release. 
> > > > > > > Does
> > > > > > > anyone have availability to lead the release?
> > > > > > >
> > > > > > > Regards,
> > > > > > > Matt J
> > > > > > >
> > > > > > > On Wed, Jul 13, 2022 at 9:35 AM sebb  > > > > > > (mailto:seb...@gmail.com)> wrote:
> > > > > > > >
> > > > > > > > It looks like Commons does not have the concept of Alpha 
> > > > > > > > releases.
> > > > > > > >
> > > > > > > > https://commons.apache.org/releases/versioning.html
> > > > > > > >
> > > > > > > > Sorry, I must have been thinking of a different project.
> > > > > > > >
> > > > > > > > Sebb
> > > > > > > >
> > > > > > > > On Wed, 13 Jul 2022 at 01:36, Gary Gregory 
> > > > > > > > mailto:garydgreg...@gmail.com)> wrote:
> > > > > > > > >
> > > > > > > > > A beta is a good idea IMO.
> > > > > > > > >
> > > > > > > > > Gary
> > > > > > > > >
> > > > > > > > > On Tue, Jul 12, 2022, 17:19 Matt Juntunen 
> > > > > > > > >  > > > > > > > > (mailto:matt.a.juntu...@gmail.com)> wrote:
> > > > > > > > >
> > > > > > > > > > Based on what I'm hearing, I'm thinking a beta release 
> > > > > > > > > > might be
> > > > > > > > > > appropriate. That would give consumers a chance to move 
> > > > > > > > > > away from the
> > > > > > > > > > previous version while giving us a chance to 

Re: [Math][Statistics] Beta release?

[Matt Juntunen]

+1

It would be great to get this code out to developers.

Regards,
Matt J

On Mon, Jul 25, 2022 at 11:46 AM Gilles Sadowski  wrote:
>
> Le lun. 25 juil. 2022 à 16:38, Alex Herbert  a 
> écrit :
> >
> > On Mon, 25 Jul 2022 at 14:37, Gilles Sadowski  wrote:
> >
> > > Hello.
> > >
> > > How about making a "beta" release of the next major version:
> > > 4.0-beta1
> > > ?
> > >
> > > This
> > >https://commons.apache.org/
> > > page refers to a "1.0-beta1" release [Statistics] that does not
> > > seem to exist.  This is a required dependency for [Math].
> > >
> >
> > I have been held up with other things so have not made progress on the
> > releases: Numbers -> RNG -> Statistics
> >
> > Statistics requires:
> >
> > - a new version of numbers to obtain the updated more accurate Brent solver
> > for the inverse CDF computation, plus all the work on the beta and gamma
> > functions. - a new version of RNG that has updated distribution samplers
> >
> > I think numbers could be released now.
> >
> > Ideally I would like to add a SplittableUniformRandomProvider interface to
> > RNG before it is released with the new XBG generators. These are splittable
> > in the JDK and it makes sense to do this now as RNG now supports Java 8 and
> > this functionality applies to Splittable streams. This is not essential and
> > it could be released as it is. However the splittable functionality may be
> > limited if added later with constraints of binary compatibility. I would
> > rather try to put it in now. I have done a lot of thinking on adding to the
> > API so I could try and put this up on a Jira ticket for discussion.
>
> IMHO, we should expose the current, several years old, state of [Math] so
> that users may become aware of what they miss out (in [RNG], [Numbers]
> and [Geometry]) by still using version 3.6.1.
> A release makes it easier for application developers to test (and perhaps
> provide feedback and contribute here).  A "beta" release will allow us to fix
> things without BC constraints.
> We could also make a "beta" release of [RNG] (1.5-beta1), on which
> [Statistics] (1.0-beta1) and [Math] (4.0-beta1) would depend, with the
> same advantage.
>
> Best,
> Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: Re: [fileupload] Have a FileUpload release (after 3.5 years)

[Matt Juntunen]

Sounds good. Do you know of anything else that needs to be done? I'm
guessing we can hold off on a full 1.x migration guide until the full
2.0.0 version.

-Matt J

On Sun, Jul 17, 2022 at 2:13 PM Gary Gregory  wrote:
>
> We should at least remove deprecated elements.
>
> Gary
>
> On Sun, Jul 17, 2022 at 10:49 AM Matt Juntunen
>  wrote:
> >
> > I am going to put the 2.0.0-beta1 release on my TODO list. I am
> > currently working toward a release of commons-text, so I can't be sure
> > on a timeline. If anyone has questions or time to pick this up, please
> > let me know.
> >
> > Regards,
> > Matt J
> >
> > On Fri, Jul 15, 2022 at 12:35 PM Matt Juntunen
> >  wrote:
> > >
> > > It sounds like we've agreed on creating a 2.0.0-beta1 release. Does
> > > anyone have availability to lead the release?
> > >
> > > Regards,
> > > Matt J
> > >
> > > On Wed, Jul 13, 2022 at 9:35 AM sebb  wrote:
> > > >
> > > > It looks like Commons does not have the concept of Alpha releases.
> > > >
> > > > https://commons.apache.org/releases/versioning.html
> > > >
> > > > Sorry, I must have been thinking of a different project.
> > > >
> > > > Sebb
> > > >
> > > > On Wed, 13 Jul 2022 at 01:36, Gary Gregory  
> > > > wrote:
> > > > >
> > > > > A beta is a good idea IMO.
> > > > >
> > > > > Gary
> > > > >
> > > > > On Tue, Jul 12, 2022, 17:19 Matt Juntunen  
> > > > > wrote:
> > > > >
> > > > > > Based on what I'm hearing, I'm thinking a beta release might be
> > > > > > appropriate. That would give consumers a chance to move away from 
> > > > > > the
> > > > > > previous version while giving us a chance to test and fine-tune the
> > > > > > API. Thoughts?
> > > > > >
> > > > > > Regards,
> > > > > > Matt J
> > > > > >
> > > > > > On Tue, Jul 12, 2022 at 4:15 PM Christoph Grüninger 
> > > > > > 
> > > > > > wrote:
> > > > > > >
> > > > > > > Publishing a first release candidate might help. Currently there 
> > > > > > > is no
> > > > > > > indication for anybody to invest in testing FileUpload.
> > > > > > >
> > > > > > > In doubt: release early, release often. People are using 
> > > > > > > FileUpload
> > > > > > > together with vulnerable dependencies!
> > > > > > >
> > > > > > > Bye
> > > > > > > Christoph
> > > > > > >
> > > > > > > -
> > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > > > > >
> > > > > >
> > > > > > -
> > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > > > >
> > > > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [all] SBOM Generation

[Matt Juntunen]

Sounds good. I've moved the discussion to the
security-disc...@community.apache.org mailist list [1].

Regards,
Matt J

[1] https://lists.apache.org/thread/l8661o0t1r8498bhy01wdwg1s2kkhogy

On Sun, Jul 17, 2022 at 11:11 AM Gary Gregory  wrote:
>
> On Sun, Jul 17, 2022 at 11:00 AM sebb  wrote:
> >
> > On Sun, 17 Jul 2022 at 15:45, Matt Juntunen  
> > wrote:
> > >
> > > Hello all,
> > >
> > > Steve Springett recently created a PR [1] for commons-parent that
> > > introduces the generation of software bill of materials (SBOM)
> > > artifacts into the build process. First of all, thank you, Steve.
> > > Secondly, I believe this is an important topic that should be
> > > addressed by our community. SBOMs contain metadata that can be used in
> > > application security contexts and software supply chain analysis. They
> > > seem to be becoming increasingly important as the software industry
> > > places a greater emphasis on cybersecurity. I have a small amount of
> > > experience with these types of files from my day job. My team will
> > > soon begin generating them for all of our projects in order to allow
> > > automated tools to better track CVEs and report to our customers on
> > > the security of our applications. The questions I believe we need to
> > > answer as a community are:
> > >
> > > 1. Do we want to include SBOMs in our Maven build artifacts?
> > > 2. If so, what format do we want to use?
> > >
> > > In regard to the first question, I believe that we would need a good
> > > reason to *not* include these (or similar) artifacts. It's a simple
> > > service we can provide to help our users maintain good cybersecurity
> > > practices. As the provider of a number of hugely popular open-source
> > > libraries, I would love to see us take the lead on ensuring the
> > > security of the Java ecosystem.
> > >
> > > For question two, there are a few SBOM standards out there, notably
> > > SPDX [2] and CycloneDX [3] (which is what Steve included in his PR). I
> > > am not well versed in the exact differences between the formats, but
> > > CycloneDX seems to have better Java support and a large number of
> > > useful tools, such as the Maven plugin used in Steve's PR.
> > >
> > > If we can agree on answers to the two questions above, then we can
> > > move forward and start discussing details. Thank you all for your
> > > time.
> >
> > SBOMs presumably apply to all ASF software, so it seems to me it would
> > be sensible to address this at ASF level.
> > It would be silly for each project to generate the data differently,
> > even if only slightly.
> > Once a format is settled upon, I would expect it to be implemented via
> > the Apache POM, rather than by every Maven Java project.
> >
> > I think the mailing list for this is probably
> > security-disc...@community.apache.org:
> > https://lists.apache.org/list.html?security-disc...@community.apache.org
>
> I agree with Sebb.
>
> Note that the CycloneDX plugin does not work correctly for
> multi-module Maven projects. See the PR for my results.
>
> Gary
>
> >
> > > Regards,
> > > Matt J
> > >
> > > [1] https://github.com/apache/commons-parent/pull/122
> > > [2] https://spdx.dev/
> > > [3] https://cyclonedx.org/
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: Re: [fileupload] Have a FileUpload release (after 3.5 years)

[Matt Juntunen]

I am going to put the 2.0.0-beta1 release on my TODO list. I am
currently working toward a release of commons-text, so I can't be sure
on a timeline. If anyone has questions or time to pick this up, please
let me know.

Regards,
Matt J

On Fri, Jul 15, 2022 at 12:35 PM Matt Juntunen
 wrote:
>
> It sounds like we've agreed on creating a 2.0.0-beta1 release. Does
> anyone have availability to lead the release?
>
> Regards,
> Matt J
>
> On Wed, Jul 13, 2022 at 9:35 AM sebb  wrote:
> >
> > It looks like Commons does not have the concept of Alpha releases.
> >
> > https://commons.apache.org/releases/versioning.html
> >
> > Sorry, I must have been thinking of a different project.
> >
> > Sebb
> >
> > On Wed, 13 Jul 2022 at 01:36, Gary Gregory  wrote:
> > >
> > > A beta is a good idea IMO.
> > >
> > > Gary
> > >
> > > On Tue, Jul 12, 2022, 17:19 Matt Juntunen  
> > > wrote:
> > >
> > > > Based on what I'm hearing, I'm thinking a beta release might be
> > > > appropriate. That would give consumers a chance to move away from the
> > > > previous version while giving us a chance to test and fine-tune the
> > > > API. Thoughts?
> > > >
> > > > Regards,
> > > > Matt J
> > > >
> > > > On Tue, Jul 12, 2022 at 4:15 PM Christoph Grüninger 
> > > > wrote:
> > > > >
> > > > > Publishing a first release candidate might help. Currently there is no
> > > > > indication for anybody to invest in testing FileUpload.
> > > > >
> > > > > In doubt: release early, release often. People are using FileUpload
> > > > > together with vulnerable dependencies!
> > > > >
> > > > > Bye
> > > > > Christoph
> > > > >
> > > > > -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >
> > > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >

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

[all] SBOM Generation

[Matt Juntunen]

Hello all,

Steve Springett recently created a PR [1] for commons-parent that
introduces the generation of software bill of materials (SBOM)
artifacts into the build process. First of all, thank you, Steve.
Secondly, I believe this is an important topic that should be
addressed by our community. SBOMs contain metadata that can be used in
application security contexts and software supply chain analysis. They
seem to be becoming increasingly important as the software industry
places a greater emphasis on cybersecurity. I have a small amount of
experience with these types of files from my day job. My team will
soon begin generating them for all of our projects in order to allow
automated tools to better track CVEs and report to our customers on
the security of our applications. The questions I believe we need to
answer as a community are:

1. Do we want to include SBOMs in our Maven build artifacts?
2. If so, what format do we want to use?

In regard to the first question, I believe that we would need a good
reason to *not* include these (or similar) artifacts. It's a simple
service we can provide to help our users maintain good cybersecurity
practices. As the provider of a number of hugely popular open-source
libraries, I would love to see us take the lead on ensuring the
security of the Java ecosystem.

For question two, there are a few SBOM standards out there, notably
SPDX [2] and CycloneDX [3] (which is what Steve included in his PR). I
am not well versed in the exact differences between the formats, but
CycloneDX seems to have better Java support and a large number of
useful tools, such as the Maven plugin used in Steve's PR.

If we can agree on answers to the two questions above, then we can
move forward and start discussing details. Thank you all for your
time.

Regards,
Matt J

[1] https://github.com/apache/commons-parent/pull/122
[2] https://spdx.dev/
[3] https://cyclonedx.org/

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

Re: Re: [fileupload] Have a FileUpload release (after 3.5 years)

[Matt Juntunen]

It sounds like we've agreed on creating a 2.0.0-beta1 release. Does
anyone have availability to lead the release?

Regards,
Matt J

On Wed, Jul 13, 2022 at 9:35 AM sebb  wrote:
>
> It looks like Commons does not have the concept of Alpha releases.
>
> https://commons.apache.org/releases/versioning.html
>
> Sorry, I must have been thinking of a different project.
>
> Sebb
>
> On Wed, 13 Jul 2022 at 01:36, Gary Gregory  wrote:
> >
> > A beta is a good idea IMO.
> >
> > Gary
> >
> > On Tue, Jul 12, 2022, 17:19 Matt Juntunen  wrote:
> >
> > > Based on what I'm hearing, I'm thinking a beta release might be
> > > appropriate. That would give consumers a chance to move away from the
> > > previous version while giving us a chance to test and fine-tune the
> > > API. Thoughts?
> > >
> > > Regards,
> > > Matt J
> > >
> > > On Tue, Jul 12, 2022 at 4:15 PM Christoph Grüninger 
> > > wrote:
> > > >
> > > > Publishing a first release candidate might help. Currently there is no
> > > > indication for anybody to invest in testing FileUpload.
> > > >
> > > > In doubt: release early, release often. People are using FileUpload
> > > > together with vulnerable dependencies!
> > > >
> > > > Bye
> > > > Christoph
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: Re: [fileupload] Have a FileUpload release (after 3.5 years)

[Matt Juntunen]

Based on what I'm hearing, I'm thinking a beta release might be
appropriate. That would give consumers a chance to move away from the
previous version while giving us a chance to test and fine-tune the
API. Thoughts?

Regards,
Matt J

On Tue, Jul 12, 2022 at 4:15 PM Christoph Grüninger  wrote:
>
> Publishing a first release candidate might help. Currently there is no
> indication for anybody to invest in testing FileUpload.
>
> In doubt: release early, release often. People are using FileUpload
> together with vulnerable dependencies!
>
> Bye
> Christoph
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [collections] JMH results for IndexedLinkedList

[Matt Juntunen]

Is this algorithm and its implementation entirely your own work? If
so, first of all, that's awesome! Thanks for the contribution! Second,
go ahead and update the license. You'll also need to have a
Contributor License Agreement [1] on file with the ASF. I think that
covers it. If I'm forgetting something, someone please chime in.

Regards,
Matt J

[1] https://www.apache.org/licenses/contributor-agreements.html#clas

On Tue, Jul 12, 2022 at 4:08 PM Rodion Efremov  wrote:
>
> Hello,
>
> Should I change the license from MIT to Apache License 2.0 before PRing it?
>
> Best regards,
> rodde
>
> ti 12.7.2022 klo 22.49 Matt Juntunen  kirjoitti:
>
> > Thanks! We should be ready for you to put together a PR for this. Have
> > we cleared any licensing or copyright issues on this algorithm? I
> > can't recall.
> >
> > Regards,
> > Matt J
> >
> > On Tue, Jul 12, 2022 at 2:06 AM Rodion Efremov 
> > wrote:
> > >
> > > Hello,
> > >
> > > I have added the benchmark data (both my and Matt's) to the JIRA issue.
> > > Please see the https://issues.apache.org/jira/browse/COLLECTIONS-797
> > >
> > > Best  regards,
> > > rodde
> > >
> > > On Tue, Jul 12, 2022 at 2:34 AM Alex Herbert 
> > > wrote:
> > >
> > > > On Mon, 11 Jul 2022 at 17:16, Gilles Sadowski 
> > > > wrote:
> > > >
> > > > > Le lun. 11 juil. 2022 à 09:51, Rodion Efremov 
> > a
> > > > > écrit :
> > > > > >
> > > > > > Hi Gilles,
> > > > > >
> > > > > > Would it be sufficient to include .txt files for the tables and the
> > > > .ods
> > > > > > file provided by Matt?
> > > > >
> > > > > It would be more handy for readers that tables are inserted "inline"
> > > > > within a comment (using the JIRA syntax) and plots are uploaded
> > > > > as PNG images.  See e.g. this report:
> > > > > https://issues.apache.org/jira/browse/NUMBERS-156
> > > >
> > > >
> > > > Note that the Jira web editor will accept a table copied from
> > > > Excel/OpenOffice and pasted in when in 'Visual' mode. You can then
> > switch
> > > > from 'Visual' to 'Text' mode to see the raw JIRA syntax and make
> > changes to
> > > > improve the layout. The 'Visual' mode has some editor buttons to
> > manipulate
> > > > the table.
> > > >
> > > > Alex
> > > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >

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

Re: [collections] JMH results for IndexedLinkedList

[Matt Juntunen]

Thanks! We should be ready for you to put together a PR for this. Have
we cleared any licensing or copyright issues on this algorithm? I
can't recall.

Regards,
Matt J

On Tue, Jul 12, 2022 at 2:06 AM Rodion Efremov  wrote:
>
> Hello,
>
> I have added the benchmark data (both my and Matt's) to the JIRA issue.
> Please see the https://issues.apache.org/jira/browse/COLLECTIONS-797
>
> Best  regards,
> rodde
>
> On Tue, Jul 12, 2022 at 2:34 AM Alex Herbert 
> wrote:
>
> > On Mon, 11 Jul 2022 at 17:16, Gilles Sadowski 
> > wrote:
> >
> > > Le lun. 11 juil. 2022 à 09:51, Rodion Efremov  a
> > > écrit :
> > > >
> > > > Hi Gilles,
> > > >
> > > > Would it be sufficient to include .txt files for the tables and the
> > .ods
> > > > file provided by Matt?
> > >
> > > It would be more handy for readers that tables are inserted "inline"
> > > within a comment (using the JIRA syntax) and plots are uploaded
> > > as PNG images.  See e.g. this report:
> > > https://issues.apache.org/jira/browse/NUMBERS-156
> >
> >
> > Note that the Jira web editor will accept a table copied from
> > Excel/OpenOffice and pasted in when in 'Visual' mode. You can then switch
> > from 'Visual' to 'Text' mode to see the raw JIRA syntax and make changes to
> > improve the layout. The 'Visual' mode has some editor buttons to manipulate
> > the table.
> >
> > Alex
> >

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

Re: [fileupload] Have a FileUpload release (after 3.5 years)

[Matt Juntunen]

Hello,

Does anyone know what the state of 2.0 development is here? It looks
like the last feature-related changes were from Sept 2021. Is there
anything preventing a release?

Regards,
Matt J

On Mon, Jul 11, 2022 at 9:51 AM Christoph Grüninger  wrote:
>
> Dear Apaches!
>
> Apache FileUpload saw its last release in December 2018. Since then security 
> issues have been found in some dependencies and the Jakarta namespace was 
> introduced. More improvements are part of trunk.
>
> What needs to be done to get a FileUpload release out of the door? What kind 
> of help can we users provide? What needs to be done by Apache developers?
>
> It's not only me, but Apache Wicket, Jenkins, Piranha Cloud and some more:
> https://issues.apache.org/jira/browse/FILEUPLOAD-309
> (and similar -343, -345).
>
> Kind regards,
> Christoph

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

Re: [collections] JMH results for IndexedLinkedList

[Matt Juntunen]

Hello rodde,

Thanks for your patience while I looked at this. I've made a PR [1] on
your benchmark project with an updated benchmark class. (I used the
completely uninspired class name of IndexedLinkedListPerformance2 :-)
The results back up what you've been saying about the performance of
this list implementation. I've attached a spreadsheet summarizing the
data for a number of different operations along with some images of
some of the most interesting comparisons. I've compared results for
java.util.ArrayList, java.util.LinkedList,
org.apache.commons.collections4.list.TreeList, and
com.github.coderodde.util.IndexedLinkedList (the list in question
here) using JDK 18 on list sizes of 10, 100, 1000, and 1.

Below are some notes on the attached images.
- get-random.png - Displays timings for element access at random
indices. As expected, ArrayList is by far the best. TreeList and
IndexedLinkedList are relatively close to each other but
IndexedLinkedList is consistently faster. LinkedList was too terrible
to even include on the graph.
- iterate.png - Displays timings for list traversal using the list's
iterator. This was unexpectedly bad for TreeList, which performed far
worse than the others. The performance of IndexedLinkedList was on par
with the JDK lists overall.
- iterate-and-modify.png - Displays timings for iterating through the
list while randomly adding and removing elements via the iterator.
IndexedLinkedList did extraordinarily well here, with performance very
close to LinkedList. Surprisingly, TreeList did worse than all of the
others, including ArrayList.

Overall, I think this list implementation would be a good option to
include in commons-collections. Does anyone have any objections to
opening a Jira ticket to pursue this?

Regards,
Matt J

[1] https://github.com/coderodde/IndexedLinkedListBenchmark/pull/3

On Sun, Jul 10, 2022 at 4:16 AM Bruno Kinoshita  wrote:
>
> Hi Rodde,
>
> It has been almost a week since your last response. Did you take a look at
> > my work?
> >
>
> Please note that we are all volunteers here, so sometimes we may be able to
> respond quickly, others we may take a few days/weeks/months/...
>
> I know Matt is active in other Apache mailing lists, and that he works on
> multiple Apache components. Besides also having $work, personal life, etc.,
> of course. So please be patient :)
>
> Cheers
> -Bruno
>
> On Sun, 10 Jul 2022 at 17:03, Rodion Efremov  wrote:
>
> > Hi Matt,
> >
> > It has been almost a week since your last response. Did you take a look at
> > my work?
> >
> > Best regards,
> > rodde
> >
> > ma 4.7.2022 klo 20.51 Matt Juntunen  kirjoitti:
> >
> > > Thanks, rodde! I should have some time this week to take a closer
> > > look. I plan on playing with the benchmarks a bit on my own. I'll let
> > > you know what I find.
> > >
> > > Regards,
> > > Matt J
> > >
> > > On Mon, Jul 4, 2022 at 4:53 AM Rodion Efremov 
> > wrote:
> > > >
> > > > Hi Matt and community,
> > > >
> > > > I have compiled the benchmark result data into 3 tables [1] (three
> > > > different load sizes) [2]. If nothing else, IndexedLiinkedList (called
> > > > RoddeList in output) is faster than both java.util.LinkedList and
> > > TreeList.
> > > >
> > > > If, for further discussion, you require something else, please let me
> > > know.
> > > >
> > > > Best regards,
> > > > rodde
> > > >
> > > > [1] https://github.com/coderodde/indexedLinkedList/#benchmark-with-jmh
> > > > [2]
> > > >
> > >
> > https://github.com/coderodde/IndexedLinkedListBenchmark/blob/main/src/main/java/com/coderodde/IndexedLinkedListPerformance.java
> > > >
> > > > On Fri, Jul 1, 2022 at 6:11 AM Matt Juntunen <
> > matt.a.juntu...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hello rodde,
> > > > >
> > > > > Thank you for sending me a reminder on this. Unfortunately, I haven't
> > > > > had time to look at the code yet. Gilles suggestions are something I
> > > > > would like to see as well. Having tables of JMH results for the
> > > > > different algorithms at different sizes would be very helpful.
> > > > >
> > > > > Regards,
> > > > > Matt J
> > > > >
> > > > > On Thu, Jun 30, 2022 at 11:34 AM Gilles Sadowski <
> > gillese...@gmail.com
> > > >
> > > > > wrote:
> > > > > >
> > > > > > Hello.
> > > > &g

CVE-2022-33980: Apache Commons Configuration insecure interpolation defaults

[Matt Juntunen]

Severity: Moderate

Description:

Apache Commons Configuration performs variable interpolation, allowing 
properties to be dynamically evaluated and expanded. The standard format for 
interpolation is "${prefix:name}", where "prefix" is used to locate an instance 
of org.apache.commons.configuration2.interpol.Lookup that performs the 
interpolation. Starting with version 2.4 and continuing through 2.7, the set of 
default Lookup instances included interpolators that could result in arbitrary 
code execution or contact with remote servers. These lookups are:
- "script" - execute expressions using the JVM script execution engine 
(javax.script)
- "dns" - resolve dns records
- "url" - load values from urls, including from remote servers

Applications using the interpolation defaults in the affected versions may be 
vulnerable to remote code execution or unintentional contact with remote 
servers if untrusted configuration values are used.

Users are recommended to upgrade to Apache Commons Configuration 2.8.0, which 
disables the problematic interpolators by default.

Mitigation:

Upgrade to version Apache Commons Configuration 2.8.0


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

Re: [collections] JMH results for IndexedLinkedList

[Matt Juntunen]

Thanks, rodde! I should have some time this week to take a closer
look. I plan on playing with the benchmarks a bit on my own. I'll let
you know what I find.

Regards,
Matt J

On Mon, Jul 4, 2022 at 4:53 AM Rodion Efremov  wrote:
>
> Hi Matt and community,
>
> I have compiled the benchmark result data into 3 tables [1] (three
> different load sizes) [2]. If nothing else, IndexedLiinkedList (called
> RoddeList in output) is faster than both java.util.LinkedList and TreeList.
>
> If, for further discussion, you require something else, please let me know.
>
> Best regards,
> rodde
>
> [1] https://github.com/coderodde/indexedLinkedList/#benchmark-with-jmh
> [2]
> https://github.com/coderodde/IndexedLinkedListBenchmark/blob/main/src/main/java/com/coderodde/IndexedLinkedListPerformance.java
>
> On Fri, Jul 1, 2022 at 6:11 AM Matt Juntunen 
> wrote:
>
> > Hello rodde,
> >
> > Thank you for sending me a reminder on this. Unfortunately, I haven't
> > had time to look at the code yet. Gilles suggestions are something I
> > would like to see as well. Having tables of JMH results for the
> > different algorithms at different sizes would be very helpful.
> >
> > Regards,
> > Matt J
> >
> > On Thu, Jun 30, 2022 at 11:34 AM Gilles Sadowski 
> > wrote:
> > >
> > > Hello.
> > >
> > > Le jeu. 30 juin 2022 à 07:54, Rodion Efremov  a
> > écrit :
> > > >
> > > > Hi Matt and community,
> > > >
> > > > Have you take a look at my work? If so, what do you think?
> > >
> > > Perhaps you missed that feedback:
> > >   https://markmail.org/message/y3tozjdke2ivz3dr
> > >
> > > >
> > > > Best regards,
> > > > rodde
> > > >
> > > > to 23.6.2022 klo 19.06 Matt Juntunen 
> > kirjoitti:
> > > >
> > > > > Hello,
> > > > >
> > > > > Thanks for providing the data here. I will hopefully have time to
> > take
> > > > > a look at this over the weekend. Send me a ping here on the dev list
> > > > > if you don't hear back from me (or someone else) within a week.
> > > > >
> > > > > Regards,
> > > > > Matt J
> > > > >
> > > > > On Tue, Jun 21, 2022 at 7:22 AM Rodion Efremov 
> > > > > wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Data structure: IndexedLinkedList
> > > > > > <https://github.com/coderodde/IndexedLinkedList>
> > > > > > Benchmark: IndexedLinkedListBenchmark
> > > > > > <https://github.com/coderodde/IndexedLinkedListBenchmark>
> > > > > >
> > > > > > Benchmark output:
> > > > > > https://github.com/coderodde/indexedLinkedList/#benchmark-output
> > > > > >
> > > > > > From the benchmark output, we can judge that IndexedLinkedList
> > > > > outperforms
> > > > > > both java.util.LinkedList and the Apache Commons Collections
> > TreeList.
> > > > > It,
> > > > > > however, does not seem to supersede the java.util.ArrayList.
> > > > > >
> > > > > > Basically, I would expect the IndexedLinkedList to beat the
> > ArrayList
> > > > > where
> > > > > > we have a lot of following operations:
> > > > > >
> > > > > >- addFirst(E)
> > > > > >- add(int, E)
> > > > > >- remove(int)
> > > > > >
> > > > > > So, what do you think? I am getting anywhere with that?
> > > > > >
> > > > > > Best regards,
> > > > > > rodde
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >

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

[ANNOUNCEMENT] Apache Commons Configuration Version 2.8.0 Released

[Matt Juntunen]

The Apache Commons Team is pleased to announce the availability of
version 2.8.0 of "Apache Commons Configuration".

Apache Commons Configuration contains tools to assist in the reading of
configuration/preferences files in various formats.

Changes in this version include:

New features:
o Implement Iterable in ImmutableNode #74. Thanks to SethiPandi.
o Add PropertiesConfigurationLayout.getBlankLinesBefore() and deprecate
  getBlancLinesBefore(). Thanks to Gary Gregory.
o Add PropertiesConfigurationLayout.setBlankLinesBefore() and deprecate
  setBlancLinesBefore(). Thanks to Gary Gregory.
o Add PropertiesConfigurationLayout.PropertyLayoutData.getBlankLines() and
  deprecate getBlancLines(). Thanks to Gary Gregory.
o Add PropertiesConfigurationLayout.PropertyLayoutData.setBlankLines() and
  deprecate setBlancLines(). Thanks to Gary Gregory.
o CONFIGURATION-789:  Add ImmutableConfiguration.getEnum() methods. Thanks to
  Gary Gregory.
o CONFIGURATION-789:  Add ImmutableConfiguration.getDuration() methods. Thanks
  to Gary Gregory.

Fixed Bugs:
o CONFIGURATION-753:  Make interpolation of collections and arrays in
  ConfigurationInterpolator consistent with behavior of
  DefaultConversionHandler. Add ConfigurationInterpolator.setStringConverter to
  allow customized string conversion behavior.
o CONFIGURATION-795:  Computation of blank lines after header comment #82.
  Thanks to dpeger.
o CONFIGURATION-801:  Remove redundant initializer #110. Thanks to
  Arturo Bernal.
o CONFIGURATION-802:  Use final #111. Thanks to Arturo Bernal.
o CONFIGURATION-803:  Java 8 lambda improvements and more #112. Thanks to
  Arturo Bernal.
o CONFIGURATION-804:  Redundant local variable #113. Thanks to Arturo Bernal.
o CONFIGURATION-805:  Use try with resource #114. Thanks to Arturo Bernal.
o CONFIGURATION-805:  [Javadoc] Specify that typed getList returns null for
  missing key #100. Thanks to Roman Zaynetdinov.
o Mention EnvironmentConfiguration in the list of configuration sources #45.
  Thanks to Oliver B. Fischer.
o CONFIGURATION-808:  DefaultListDelimiterHandler.escapeList working only for
  List>String< #137. Thanks to cigaly.
o Use final #141. Thanks to Arturo Bernal.
o Replace test asserts by simpler but equivalent calls. #139 Thanks to
  Arturo Bernal.
o CONFIGURATION-764:  Single Variable Interpolation #182. Thanks to Ning Zhang,
  Matt Juntunen, Bruno P. Kinoshita, Gary Gregory.
o Implement proper concurrency in ConstantLookup. Thanks to Gary Gregory.
o CONFIGURATION-813:  Support new namespace jakarta.mail.* used by javamail 2.0+
  (first release October 2020) #186. Thanks to Dependabot.

Changes:
o Unclosed file handle when reading config from JAR file URL. Add and use
  FileBasedBuilderProperties.setURL(URL, URLConnectionOptions). Thanks to
  Robin Jansohn, Gary Gregory, Rob Spoor.
o Make default interpolation prefix lookups configurable via system property.
  Remove dns, url, and script lookups from defaults. If these lookups are
  required for use in AbstractConfiguration subclasses, they must be enabled
  via system property. See ConfigurationInterpolator.getDefaultPrefixLookups()
  for details.
o Bump actions/cache from 2 to 3.0.4 #99, #151, #169. Thanks to Dependabot,
  Gary Gregory.
o Bump actions/checkout from 1 to 3 #47, #62, #70, #85, #150, #163. Thanks to
  Dependabot.
o Bump actions/setup-java from 1.4.0 to 3 #63, #65, #73, #174. Thanks to
  Dependabot, Gary Gregory.
o Bump codeql-action from v1 to v2. Thanks to Dependabot, Matt Juntunen.
o Bump Spring dependency versions:
org.springframework:spring-beans 4.3.26.RELEASE -> 5.3.21
org.springframework:spring-context 4.3.26.RELEASE -> 5.3.21
org.springframework:spring-core 4.3.26.RELEASE -> 5.3.21
org.springframework:spring-test 4.3.26.RELEASE -> 5.3.21
#165, #172 Thanks to Dependabot, Matt Juntunen, kinow, Gary Gregory.
o Bump commons-parent from 52 to 53. Thanks to Dependabot, Matt Juntunen.
o CONFIGURATION-787:  Bump Apache Commons Lang from 3.9 to 3.12.0. Thanks to
  Gary Gregory.
o CONFIGURATION-790:  Bump com.fasterxml.jackson.core:jackson-databind
  from 2.10.3 to 2.13.3, #60. Thanks to Gary Gregory, Dependabot.
o Bump Slf4j test dependencies:
org.slf4j:slf4j-api 1.7.26 -> 1.7.33,
org.slf4j:slf4j-ext 1.7.26 -> 1.7.33,
org.slf4j:slf4j-log4j12 1.7.26 -> 1.7.33,
org.slf4j:slf4j-nop 1.7.26 -> 1.7.33. Thanks to Gary Gregory.
o Bump commons-parent from 50 to 52. Thanks to Dependabot.
o Bump mailapi from 1.6.4 to 1.6.7 #48. Thanks to Dependabot, Gary Gregory.
o Bump spotbugs-maven-plugin from 3.1.12.2 to 4.7.0.0, #55, #75, #79, #93, #116,
  #183. Thanks to Dependabot, Gary Gregory.
o Bump hsqldb from 2.5.0 to 2.5.2 #54, #128. Thanks to Dependabot.
o Bump commons-text from 1.8 to 1.9. Thanks to Gary Gregory.
o Bump servlet-api from 2.4 to 2.5 #58. Thanks to Gary Gregory.
o Bump maven-checkstyle-plugin from 3.1.0 to 3.1.2, #57, #97. Thanks to
  Gary Gregory.
o Bump commons-pool2

Re: [VOTE] Release Apache Commons Configuration 2.8.0 based on RC3

[Matt Juntunen]

Hello Alex,

That would remove those files from the javadoc completely. As of now,
the generated files are included in the javadoc [1]. These files are
part of the public API (per previous releases) so I don't believe we
would want them undocumented.

Regards,
Matt J

[1] https://commons.apache.org/proper/commons-configuration/apidocs/index.html

On Mon, Jul 4, 2022 at 3:14 AM Alex Herbert  wrote:
>
> On Mon, 4 Jul 2022 at 03:41, Matt Juntunen 
> wrote:
>
> > I'm not sure what to do
> > about the javadoc warnings on the generated classes. From the comments
> > in the pom, this seems to have been an issue since v2.4.
> >
>
>   
> **/generated/*.java
>   
>
> Or whatever path is suitable [1].
>
> Alex
>
> [1]
> https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#sourceFileExcludes

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

[VOTE][RESULT] Release Apache Commons Configuration 2.8.0 based on RC3

[Matt Juntunen]

This vote passes with the following votes:

- Bruno Kinoshita +1 (binding)
- Gary Gregory +1 (binding)
- Matt Juntunen +1 (binding)

I will begin finalizing the release shortly.

Regards,
Matt J

On Sun, Jul 3, 2022 at 10:40 PM Matt Juntunen  wrote:
>
> Thanks, Bruno and Gary!
>
> Gary,
> I think the unit tests as a whole could use some upgrading. I'm
> picturing a conversion to JUnit 5, during which we could ensure
> compatibility with the latest JDK versions. I'm not sure what to do
> about the javadoc warnings on the generated classes. From the comments
> in the pom, this seems to have been an issue since v2.4.
>
> Regards,
> Matt J
>
> On Sun, Jul 3, 2022 at 3:10 PM Gary Gregory  wrote:
> >
> > +1
> >
> > Based on the source zip file.
> >
> > Builds OK on Java 8 and Java 11 on macOS
> >
> > SHA and ASC files OK
> >
> > Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> > Maven home: /usr/local/Cellar/maven/3.8.6/libexec
> > Java version: 1.8.0_322, vendor: Homebrew, runtime:
> > /usr/local/Cellar/openjdk@8/1.8.0+322/libexec/openjdk.jdk/Contents/Home/jre
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "mac os x", version: "12.4", arch: "x86_64", family: "mac"
> >
> > Darwin *** 21.5.0 Darwin Kernel Version 21.5.0: Tue Apr 26 21:08:22
> > PDT 2022; root:xnu-8020.121.3~4/RELEASE_X86_64 x86_64
> >
> > Gary
> >
> > On Thu, Jun 30, 2022 at 12:23 AM Matt Juntunen
> >  wrote:
> > >
> > > We have fixed quite a few bugs and added some significant enhancements
> > > since Apache Commons Configuration 2.7 was released, so I would like
> > > to release Apache Commons Configuration 2.8.0.
> > >
> > > Apache Commons Configuration 2.8.0 RC3 is available for review here:
> > > https://dist.apache.org/repos/dist/dev/commons/configuration/2.8.0-RC3
> > > (svn revision 55351)
> > >
> > > The Git tag commons-configuration-2.8.0-RC3 commit for this RC is
> > > 59e5152722198526c6ffe5361de7d1a6a87275c7 which you can browse here:
> > > 
> > > https://gitbox.apache.org/repos/asf?p=commons-configuration.git;a=commit;h=59e5152722198526c6ffe5361de7d1a6a87275c7
> > > You may checkout this tag using:
> > > git clone 
> > > https://gitbox.apache.org/repos/asf/commons-configuration.git
> > > --branch commons-configuration-2.8.0-RC3
> > > commons-configuration-2.8.0-RC3
> > >
> > > Maven artifacts are here:
> > > 
> > > https://repository.apache.org/content/repositories/orgapachecommons-1591/org/apache/commons/commons-configuration2/2.8.0/
> > >
> > > These are the artifacts and their hashes:
> > >
> > > #Release SHA-512s
> > > #Thu Jun 30 00:04:49 EDT 2022
> > > commons-configuration2-2.8.0-bin.tar.gz=7f60d1d67e10f2198f2863bb374de79a1dcfd777bc56201407b9d8015a187f9bb63b853449a402a60bb0f8c459108d1dcee06d792865a500627388d21f122ccd
> > > commons-configuration2-2.8.0-bin.zip=4f9f8d2d6ea1948cc91dc31b6fb07d0bdc1b359bd7f67685c1f8306aa93b8326ec30f4818176f3da5bae267b121f020e7a0f9dd8f6f055066fab3cbb9aebfa54
> > > commons-configuration2-2.8.0-javadoc.jar=80cca911d1bd58e3a460fc5c8ecd2129eccf84ec9e788b13dd53750454a9966cae3662f2d3af4c1eb7864b850ac36e4f4d7ee39bc842a70ca3aeefaeab94f128
> > > commons-configuration2-2.8.0-sources.jar=6d52b9e84c522bb908492028117da786ca041e10ba456bf2162d4ede5467a8e53a4dc05d4338d9e29b445129a7707f2f8bfa8c8590c23777012649333686609e
> > > commons-configuration2-2.8.0-src.tar.gz=0f73494a124f35cf4c781ca53aadc48dfff77b543a8dc9e91d781a35b4c643ca1c06bae55c1a38fbbc234cfa7aefd89862cb74bd64db56806e11de90622e8694
> > > commons-configuration2-2.8.0-src.zip=128a33001733e97d4960ad2a89ab90b717a79a9a522263ed9e1aeb4e62bd1298e9e0e9cd7918a1693f75c35168edb9d2257b0b6f4fa246cbcc3865ada7959c11
> > > commons-configuration2-2.8.0-test-sources.jar=8dd085a5cd1f07f274f067e618a74d7149662b1ea27b6253df2d8073ba7afde8c58ebfde9817e146f88ebb69ea7381f36a140253249113426bad5b8851ae8626
> > > commons-configuration2-2.8.0-tests.jar=17648ae07d2cfbae0eab7c18a2bd6adf2c9f03b72161c51055bb19d166ca1f6bd6ca4feec999cb747137895fb020fe7bf6c20a873a9ae4c3fa79a30cb159c26e
> > >
> > > I have tested this with ***'mvn clean install site'*** using:
> > > ***
> > > Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
> > > Maven home: /home/matt/tools/maven/apache-maven-3.8.4
> > > Java version: 1.8.0_322, vendor: Temurin, runtime:
> > > /home/matt/lang/java/jdk8u322-b06/jre
> > > Default locale: en_US, platform encoding: UTF-8
>

Re: [VOTE] Release Apache Commons Configuration 2.8.0 based on RC3

[Matt Juntunen]

Thanks, Bruno and Gary!

Gary,
I think the unit tests as a whole could use some upgrading. I'm
picturing a conversion to JUnit 5, during which we could ensure
compatibility with the latest JDK versions. I'm not sure what to do
about the javadoc warnings on the generated classes. From the comments
in the pom, this seems to have been an issue since v2.4.

Regards,
Matt J

On Sun, Jul 3, 2022 at 3:10 PM Gary Gregory  wrote:
>
> +1
>
> Based on the source zip file.
>
> Builds OK on Java 8 and Java 11 on macOS
>
> SHA and ASC files OK
>
> Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> Maven home: /usr/local/Cellar/maven/3.8.6/libexec
> Java version: 1.8.0_322, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk@8/1.8.0+322/libexec/openjdk.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "12.4", arch: "x86_64", family: "mac"
>
> Darwin *** 21.5.0 Darwin Kernel Version 21.5.0: Tue Apr 26 21:08:22
> PDT 2022; root:xnu-8020.121.3~4/RELEASE_X86_64 x86_64
>
> Gary
>
> On Thu, Jun 30, 2022 at 12:23 AM Matt Juntunen
>  wrote:
> >
> > We have fixed quite a few bugs and added some significant enhancements
> > since Apache Commons Configuration 2.7 was released, so I would like
> > to release Apache Commons Configuration 2.8.0.
> >
> > Apache Commons Configuration 2.8.0 RC3 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/configuration/2.8.0-RC3
> > (svn revision 55351)
> >
> > The Git tag commons-configuration-2.8.0-RC3 commit for this RC is
> > 59e5152722198526c6ffe5361de7d1a6a87275c7 which you can browse here:
> > 
> > https://gitbox.apache.org/repos/asf?p=commons-configuration.git;a=commit;h=59e5152722198526c6ffe5361de7d1a6a87275c7
> > You may checkout this tag using:
> > git clone https://gitbox.apache.org/repos/asf/commons-configuration.git
> > --branch commons-configuration-2.8.0-RC3
> > commons-configuration-2.8.0-RC3
> >
> > Maven artifacts are here:
> > 
> > https://repository.apache.org/content/repositories/orgapachecommons-1591/org/apache/commons/commons-configuration2/2.8.0/
> >
> > These are the artifacts and their hashes:
> >
> > #Release SHA-512s
> > #Thu Jun 30 00:04:49 EDT 2022
> > commons-configuration2-2.8.0-bin.tar.gz=7f60d1d67e10f2198f2863bb374de79a1dcfd777bc56201407b9d8015a187f9bb63b853449a402a60bb0f8c459108d1dcee06d792865a500627388d21f122ccd
> > commons-configuration2-2.8.0-bin.zip=4f9f8d2d6ea1948cc91dc31b6fb07d0bdc1b359bd7f67685c1f8306aa93b8326ec30f4818176f3da5bae267b121f020e7a0f9dd8f6f055066fab3cbb9aebfa54
> > commons-configuration2-2.8.0-javadoc.jar=80cca911d1bd58e3a460fc5c8ecd2129eccf84ec9e788b13dd53750454a9966cae3662f2d3af4c1eb7864b850ac36e4f4d7ee39bc842a70ca3aeefaeab94f128
> > commons-configuration2-2.8.0-sources.jar=6d52b9e84c522bb908492028117da786ca041e10ba456bf2162d4ede5467a8e53a4dc05d4338d9e29b445129a7707f2f8bfa8c8590c23777012649333686609e
> > commons-configuration2-2.8.0-src.tar.gz=0f73494a124f35cf4c781ca53aadc48dfff77b543a8dc9e91d781a35b4c643ca1c06bae55c1a38fbbc234cfa7aefd89862cb74bd64db56806e11de90622e8694
> > commons-configuration2-2.8.0-src.zip=128a33001733e97d4960ad2a89ab90b717a79a9a522263ed9e1aeb4e62bd1298e9e0e9cd7918a1693f75c35168edb9d2257b0b6f4fa246cbcc3865ada7959c11
> > commons-configuration2-2.8.0-test-sources.jar=8dd085a5cd1f07f274f067e618a74d7149662b1ea27b6253df2d8073ba7afde8c58ebfde9817e146f88ebb69ea7381f36a140253249113426bad5b8851ae8626
> > commons-configuration2-2.8.0-tests.jar=17648ae07d2cfbae0eab7c18a2bd6adf2c9f03b72161c51055bb19d166ca1f6bd6ca4feec999cb747137895fb020fe7bf6c20a873a9ae4c3fa79a30cb159c26e
> >
> > I have tested this with ***'mvn clean install site'*** using:
> > ***
> > Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
> > Maven home: /home/matt/tools/maven/apache-maven-3.8.4
> > Java version: 1.8.0_322, vendor: Temurin, runtime:
> > /home/matt/lang/java/jdk8u322-b06/jre
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "linux", version: "5.18.6-200.fc36.x86_64", arch: "amd64",
> > family: "unix"
> >
> > Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
> > Maven home: /home/matt/tools/maven/apache-maven-3.8.4
> > Java version: 11.0.14.1, vendor: Eclipse Adoptium, runtime:
> > /home/matt/lang/java/jdk-11.0.14.1+1
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "linux", version: "5.18.6-200.fc36.x86_64", arch: "amd64",
> > family: "unix"
> > ***
> >
> > Details of changes s

Re: [VOTE] Release Apache Commons Configuration 2.8.0 based on RC3

[Matt Juntunen]

m(java.io.Reader dstream, int startline,
> > [WARNING] ^
> > [WARNING] 
> > /Users/garydgregory/Downloads/cc/commons-configuration2-2.8.0-src/target/generated-sources/javacc/org/apache/commons/configuration2/plist/SimpleCharStream.java:253:
> > warning: no @param for dstream
> > [WARNING] public SimpleCharStream(java.io.Reader dstream, int startline,
> > [WARNING] ^
> > [WARNING] 
> > /Users/garydgregory/Downloads/cc/commons-configuration2-2.8.0-src/target/generated-sources/javacc/org/apache/commons/configuration2/plist/SimpleCharStream.java:253:
> > warning: no @param for startline
> > [WARNING] public SimpleCharStream(java.io.Reader dstream, int startline,
> > [WARNING] ^
> > [WARNING] 
> > /Users/garydgregory/Downloads/cc/commons-configuration2-2.8.0-src/target/generated-sources/javacc/org/apache/commons/configuration2/plist/SimpleCharStream.java:253:
> > warning: no @param for startcolumn
> > [WARNING] public SimpleCharStream(java.io.Reader dstream, int startline,
> > [WARNING] ^
> > [WARNING] 
> > /Users/garydgregory/Downloads/cc/commons-configuration2-2.8.0-src/target/generated-sources/javacc/org/apache/commons/configuration2/plist/SimpleCharStream.java:253:
> > warning: no @param for buffersize
> > [WARNING] public SimpleCharStream(java.io.Reader dstream, int startline,
> > [WARNING] ^
> > [WARNING] 
> > /Users/garydgregory/Downloads/cc/commons-configuration2-2.8.0-src/target/generated-sources/javacc/org/apache/commons/configuration2/plist/Token.java:71:
> > warning: no @return
> > [WARNING] public Object getValue() {
> > [WARNING] ^
> > [WARNING] 
> > /Users/garydgregory/Downloads/cc/commons-configuration2-2.8.0-src/target/generated-sources/javacc/org/apache/commons/configuration2/plist/Token.java:117:
> > warning: no @param for ofKind
> > [WARNING] public static Token newToken(int ofKind, String image)
> > [WARNING] ^
> > [WARNING] 
> > /Users/garydgregory/Downloads/cc/commons-configuration2-2.8.0-src/target/generated-sources/javacc/org/apache/commons/configuration2/plist/Token.java:117:
> > warning: no @param for image
> > [WARNING] public static Token newToken(int ofKind, String image)
> > [WARNING] ^
> > [WARNING] 
> > /Users/garydgregory/Downloads/cc/commons-configuration2-2.8.0-src/target/generated-sources/javacc/org/apache/commons/configuration2/plist/Token.java:117:
> > warning: no @return
> > [WARNING] public static Token newToken(int ofKind, String image)
> > [WARNING] ^
> > [WARNING] 
> > /Users/garydgregory/Downloads/cc/commons-configuration2-2.8.0-src/target/generated-sources/javacc/org/apache/commons/configuration2/plist/Token.java:83:
> > warning: no @param for kind
> > [WARNING] public Token(int kind)
> > [WARNING] ^
> > [WARNING] 
> > /Users/garydgregory/Downloads/cc/commons-configuration2-2.8.0-src/target/generated-sources/javacc/org/apache/commons/configuration2/plist/Token.java:91:
> > warning: no @param for kind
> > [WARNING] public Token(int kind, String image)
> > [WARNING] ^
> > [WARNING] 
> > /Users/garydgregory/Downloads/cc/commons-configuration2-2.8.0-src/target/generated-sources/javacc/org/apache/commons/configuration2/plist/Token.java:91:
> > warning: no @param for image
> > [WARNING] public Token(int kind, String image)
> > [WARNING] ^
> > [WARNING] 
> > /Users/garydgregory/Downloads/cc/commons-configuration2-2.8.0-src/target/generated-sources/javacc/org/apache/commons/configuration2/plist/TokenMgrError.java:50:
> > warning: no @param for str
> > [WARNING] protected static final String addEscapes(String str) {
> > [WARNING] ^
> > [WARNING] 
> > /Users/garydgregory/Downloads/cc/commons-configuration2-2.8.0-src/target/generated-sources/javacc/org/apache/commons/configuration2/plist/TokenMgrError.java:50:
> > warning: no @return
> > [WARNING] protected static final String addEscapes(String str) {
> > [WARNING] ^
> > [WARNING] 
> > /Users/garydgregory/Downloads/cc/commons-configuration2-2.8.0-src/target/generated-sources/javacc/org/apache/commons/configuration2/plist/TokenMgrError.java:107:
> > warning: no @param for EOFSeen
> > [WARNING] protected static String LexicalError(boolean EOFSeen, int
> > lexState, int errorLine, int errorColumn, String errorAfter, char
> > curChar) {
> > [WARNING] ^
> > [WARNING] 
> > /Users/garydgregory/Downloads/cc/commons-configuration2-2.8.0-src/target/generated-sources/javacc/org/apache/commons/configuration2/plist/TokenMgrError.java:107:
> > warning: no @param for lexState
> > [WARNING] protected static String LexicalError(boolean EOFSeen, int
> 

Re: [collections] JMH results for IndexedLinkedList

[Matt Juntunen]

Hello rodde,

Thank you for sending me a reminder on this. Unfortunately, I haven't
had time to look at the code yet. Gilles suggestions are something I
would like to see as well. Having tables of JMH results for the
different algorithms at different sizes would be very helpful.

Regards,
Matt J

On Thu, Jun 30, 2022 at 11:34 AM Gilles Sadowski  wrote:
>
> Hello.
>
> Le jeu. 30 juin 2022 à 07:54, Rodion Efremov  a écrit :
> >
> > Hi Matt and community,
> >
> > Have you take a look at my work? If so, what do you think?
>
> Perhaps you missed that feedback:
>   https://markmail.org/message/y3tozjdke2ivz3dr
>
> >
> > Best regards,
> > rodde
> >
> > to 23.6.2022 klo 19.06 Matt Juntunen  kirjoitti:
> >
> > > Hello,
> > >
> > > Thanks for providing the data here. I will hopefully have time to take
> > > a look at this over the weekend. Send me a ping here on the dev list
> > > if you don't hear back from me (or someone else) within a week.
> > >
> > > Regards,
> > > Matt J
> > >
> > > On Tue, Jun 21, 2022 at 7:22 AM Rodion Efremov 
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > Data structure: IndexedLinkedList
> > > > <https://github.com/coderodde/IndexedLinkedList>
> > > > Benchmark: IndexedLinkedListBenchmark
> > > > <https://github.com/coderodde/IndexedLinkedListBenchmark>
> > > >
> > > > Benchmark output:
> > > > https://github.com/coderodde/indexedLinkedList/#benchmark-output
> > > >
> > > > From the benchmark output, we can judge that IndexedLinkedList
> > > outperforms
> > > > both java.util.LinkedList and the Apache Commons Collections TreeList.
> > > It,
> > > > however, does not seem to supersede the java.util.ArrayList.
> > > >
> > > > Basically, I would expect the IndexedLinkedList to beat the ArrayList
> > > where
> > > > we have a lot of following operations:
> > > >
> > > >- addFirst(E)
> > > >- add(int, E)
> > > >- remove(int)
> > > >
> > > > So, what do you think? I am getting anywhere with that?
> > > >
> > > > Best regards,
> > > > rodde
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

[VOTE] Release Apache Commons Configuration 2.8.0 based on RC3

[Matt Juntunen]

We have fixed quite a few bugs and added some significant enhancements
since Apache Commons Configuration 2.7 was released, so I would like
to release Apache Commons Configuration 2.8.0.

Apache Commons Configuration 2.8.0 RC3 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/configuration/2.8.0-RC3
(svn revision 55351)

The Git tag commons-configuration-2.8.0-RC3 commit for this RC is
59e5152722198526c6ffe5361de7d1a6a87275c7 which you can browse here:

https://gitbox.apache.org/repos/asf?p=commons-configuration.git;a=commit;h=59e5152722198526c6ffe5361de7d1a6a87275c7
You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-configuration.git
--branch commons-configuration-2.8.0-RC3
commons-configuration-2.8.0-RC3

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1591/org/apache/commons/commons-configuration2/2.8.0/

These are the artifacts and their hashes:

#Release SHA-512s
#Thu Jun 30 00:04:49 EDT 2022
commons-configuration2-2.8.0-bin.tar.gz=7f60d1d67e10f2198f2863bb374de79a1dcfd777bc56201407b9d8015a187f9bb63b853449a402a60bb0f8c459108d1dcee06d792865a500627388d21f122ccd
commons-configuration2-2.8.0-bin.zip=4f9f8d2d6ea1948cc91dc31b6fb07d0bdc1b359bd7f67685c1f8306aa93b8326ec30f4818176f3da5bae267b121f020e7a0f9dd8f6f055066fab3cbb9aebfa54
commons-configuration2-2.8.0-javadoc.jar=80cca911d1bd58e3a460fc5c8ecd2129eccf84ec9e788b13dd53750454a9966cae3662f2d3af4c1eb7864b850ac36e4f4d7ee39bc842a70ca3aeefaeab94f128
commons-configuration2-2.8.0-sources.jar=6d52b9e84c522bb908492028117da786ca041e10ba456bf2162d4ede5467a8e53a4dc05d4338d9e29b445129a7707f2f8bfa8c8590c23777012649333686609e
commons-configuration2-2.8.0-src.tar.gz=0f73494a124f35cf4c781ca53aadc48dfff77b543a8dc9e91d781a35b4c643ca1c06bae55c1a38fbbc234cfa7aefd89862cb74bd64db56806e11de90622e8694
commons-configuration2-2.8.0-src.zip=128a33001733e97d4960ad2a89ab90b717a79a9a522263ed9e1aeb4e62bd1298e9e0e9cd7918a1693f75c35168edb9d2257b0b6f4fa246cbcc3865ada7959c11
commons-configuration2-2.8.0-test-sources.jar=8dd085a5cd1f07f274f067e618a74d7149662b1ea27b6253df2d8073ba7afde8c58ebfde9817e146f88ebb69ea7381f36a140253249113426bad5b8851ae8626
commons-configuration2-2.8.0-tests.jar=17648ae07d2cfbae0eab7c18a2bd6adf2c9f03b72161c51055bb19d166ca1f6bd6ca4feec999cb747137895fb020fe7bf6c20a873a9ae4c3fa79a30cb159c26e

I have tested this with ***'mvn clean install site'*** using:
***
Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: /home/matt/tools/maven/apache-maven-3.8.4
Java version: 1.8.0_322, vendor: Temurin, runtime:
/home/matt/lang/java/jdk8u322-b06/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.18.6-200.fc36.x86_64", arch: "amd64",
family: "unix"

Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: /home/matt/tools/maven/apache-maven-3.8.4
Java version: 11.0.14.1, vendor: Eclipse Adoptium, runtime:
/home/matt/lang/java/jdk-11.0.14.1+1
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.18.6-200.fc36.x86_64", arch: "amd64",
family: "unix"
***

Details of changes since 2.7 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/configuration/2.8.0-RC3/RELEASE-NOTES.txt

https://dist.apache.org/repos/dist/dev/commons/configuration/2.8.0-RC3/site/changes-report.html

Site:

https://dist.apache.org/repos/dist/dev/commons/configuration/2.8.0-RC3/site/index.html
(note some *relative* links are broken and the 2.8.0 directories
are not yet created - these will be OK once the site is deployed.)

JApiCmp Report (compared to 2.7):

https://dist.apache.org/repos/dist/dev/commons/configuration/2.8.0-RC3/site/japicmp.html

RAT Report:

https://dist.apache.org/repos/dist/dev/commons/configuration/2.8.0-RC3/site/rat-report.html

KEYS:
  https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 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
==

These guidelines are NOT complete.

Requirements: Git, Java, Maven.

You can validate a release from a release candidate (RC) tag as follows.

1) Clone and checkout the RC tag

git clone https://gitbox.apache.org/repos/asf/commons-configuration.git
--branch commons-configuration-2.8.0-RC3
commons-configuration-2.8.0-RC3
cd commons-configuration-2.8.0-RC3

2) Check Apache licenses

This step is not required if the site includes a RAT report page which
you then must check.

mvn apache-rat:check

3) Check binary compatibility

[CANCELLED] [VOTE] Release Apache Commons Configuration 2.8 based on RC2

[Matt Juntunen]

Hello,

Apologies for the late response. The second half of this week turned
out to be extraordinarily busy and I haven't had any time for commons.

Thank you for the detailed review, Gary. I am cancelling this vote and
will be making those changes for RC3. It may be a few days more before
I can get to it. Should I also change the version to "2.8.0" instead
of "2.8" while I'm at it?

Regards,
Matt J

On Fri, Jun 24, 2022 at 7:38 AM Gary Gregory  wrote:
>
> Where is the documentation for the new property-based toggles?
>
> It should be at least be documented here:
> https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-RC2/site/userguide/howto_basicfeatures.html#Variable_Interpolation
>
> Shouldn't the migration page also mention have a new section for this
> version on how to get the features back with the sys prop toggles on
> https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-RC2/site/userguide/upgradeto2_0.html
> ?
>
> Gary
>
> On Tue, Jun 21, 2022 at 11:47 PM Matt Juntunen
>  wrote:
> >
> > We have fixed quite a few bugs and added some significant enhancements
> > since Apache Commons Configuration 2.7 was released, so I would like
> > to release Apache Commons Configuration 2.8.
> >
> > Apache Commons Configuration 2.8 RC2 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-RC2
> > (svn revision 55251)
> >
> > The Git tag commons-configuration-2.8-RC2 commit for this RC is
> > f540433112b9a93c26c43277c3ec7a3d40565115 which you can browse here:
> > 
> > https://gitbox.apache.org/repos/asf?p=commons-configuration.git;a=commit;h=f540433112b9a93c26c43277c3ec7a3d40565115
> > You may checkout this tag using:
> > git clone https://gitbox.apache.org/repos/asf/commons-configuration.git
> > --branch commons-configuration-2.8-RC2 commons-configuration-2.8-RC2
> >
> > Maven artifacts are here:
> > 
> > https://repository.apache.org/content/repositories/orgapachecommons-1590/org/apache/commons/commons-configuration2/2.8/
> >
> > These are the artifacts and their hashes:
> >
> > #Release SHA-512s
> > #Tue Jun 21 23:27:23 EDT 2022
> > commons-configuration2-2.8-bin.tar.gz=b3f4628ecf3fc52feaf68ca13d0518d0ff5de8bea690a3fa625b91f2ffee9ef0fe1c575743d71bd035ba5d1c0be47a668ec1b28fb1953998f6723cecb8b59a38
> > commons-configuration2-2.8-bin.zip=86dc5ee9d7581b6c0b2f2807fb4f2179eec0dc4dfdb1246ffd9054a64e4511b534a4be015946403f0d0519362029cef2d4d89c684d38eaa4bd1e6af8d8b8b3a9
> > commons-configuration2-2.8-javadoc.jar=91dc9721ebea0345175d02b2d8e4bf08a255034549527edbecd382771540d85ca2423f22a4bc260d42ac33e9c3bd6b36a5fb7713b4919b58a0c06d9661285b0d
> > commons-configuration2-2.8-sources.jar=85e4f25fc9a0682bd3376de2741b48bfb6b77e98795a107c818c0bb51578cde8dd60a5e38177a6ce2a73bc4a1b9f925720321f7320fef0173c6f26c0a303bb55
> > commons-configuration2-2.8-src.tar.gz=924be9a8c0fd5f5a03d9ccd14a0bf79b83323f424fc4580084e807a5f7f242d40146cbdcd34d8d3a0098aeebe3040f77089230176ef737d649666152f2bda6ea
> > commons-configuration2-2.8-src.zip=e6695471c21e0c885b3ad5b0e0ff65a69a65cbc82a7c96d0406342f81b2efb8185b7008dfd7d49603ca96ea44761bb681aacfd997bbbae742ad922d58173305a
> > commons-configuration2-2.8-test-sources.jar=d203e063ec6b7ea16688c9015f10cf41bb3c592e990e214f6f808a20f19efe5973b3d30f4b939d571a8f4c1c2094d52c77733b59d0e7cdf412d27133fac7c7d9
> > commons-configuration2-2.8-tests.jar=6878c163de212e0617650ecbcd68887db1fc0c29f596ca773598b4ef7314e7062f4671208b8360d6ec2ca8f8408c75763912bcc545903e440fd77a6086af5c49
> >
> >
> >
> > I have tested this with ***'mvn clean install site'*** using:
> > ***
> > Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
> > Maven home: /home/matt/tools/maven/apache-maven-3.8.4
> > Java version: 1.8.0_322, vendor: Temurin, runtime:
> > /home/matt/lang/java/jdk8u322-b06/jre
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "linux", version: "5.17.12-300.fc36.x86_64", arch: "amd64",
> > family: "unix"
> >
> > Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
> > Maven home: /home/matt/tools/maven/apache-maven-3.8.4
> > Java version: 11.0.14.1, vendor: Eclipse Adoptium, runtime:
> > /home/matt/lang/java/jdk-11.0.14.1+1
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "linux", version: "5.17.12-300.fc36.x86_64", arch: "amd64",
> > family: "unix"
> > ***
> >
> > Details of changes since 2.7 are in the release notes:
> > 
> > https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-RC2/RELEASE-N

Re: [collections] JMH results for IndexedLinkedList

[Matt Juntunen]

Hello,

Thanks for providing the data here. I will hopefully have time to take
a look at this over the weekend. Send me a ping here on the dev list
if you don't hear back from me (or someone else) within a week.

Regards,
Matt J

On Tue, Jun 21, 2022 at 7:22 AM Rodion Efremov  wrote:
>
> Hi,
>
> Data structure: IndexedLinkedList
> 
> Benchmark: IndexedLinkedListBenchmark
> 
>
> Benchmark output:
> https://github.com/coderodde/indexedLinkedList/#benchmark-output
>
> From the benchmark output, we can judge that IndexedLinkedList outperforms
> both java.util.LinkedList and the Apache Commons Collections TreeList. It,
> however, does not seem to supersede the java.util.ArrayList.
>
> Basically, I would expect the IndexedLinkedList to beat the ArrayList where
> we have a lot of following operations:
>
>- addFirst(E)
>- add(int, E)
>- remove(int)
>
> So, what do you think? I am getting anywhere with that?
>
> Best regards,
> rodde

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

Re: [CANCELLED] [VOTE] Release Apache Commons Configuration 2.8 based on RC1

[Matt Juntunen]

Gary,

I was unaware of this. Is this a new convention that we've decided on?
If not, I'd prefer to wait for the next release since "2.8" is
consistent with previous commons-configuration releases and the vote
has already started on rc2.

Regards,
Matt J

On Wed, Jun 22, 2022 at 7:45 AM Gary Gregory  wrote:
>
> Please use 2.8.0, I've been using the 3 part version format for all recent
> releases. I think it would be nice to follow this naming here.
>
> Gary
>
> On Tue, Jun 21, 2022, 22:30 Matt Juntunen  wrote:
>
> > Thanks, Bruno! I'm going to go ahead and cancel this vote so I can fix
> > the README. I also noticed some inconsistency in the naming of the
> > version. In some places I called it 2.8.0 and in others 2.8. I'm going
> > to standardize on the shorter "2.8". RC2 should be out soon.
> >
> > Regards,
> > Matt J
> >
> > On Tue, Jun 21, 2022 at 1:30 AM Bruno Kinoshita  wrote:
> > >
> > > Hi Matt,
> > >
> > > Inspected NOTICE, LICENSE, RELEASE-NOTES, and found no issues. Checked
> > out
> > > the tag, and `mvn clean test install site` passed with no errors.
> > >
> > > The README is still showing 2.7 in the download instructions. I **think**
> > > one of the preparation steps uses a release-plugin goal that re-generates
> > > this file with the correct version, but I could be wrong. Not sure if
> > it's
> > > a blocker?
> > >
> > > Another thing that I noticed, but probably just nit-picking; opening a
> > zip
> > > and a tar.gz file from dist/source folders each, and opening each file on
> > > Ubuntu LTS, I think not all files are UTF-8 encoded. The
> > RELEASE-NOTES.txt
> > > fails to open on my Mousepad editor. It pops up an error dialogue that
> > lets
> > > me try to guess the encoding to open it. Not an issue for me as I think
> > it
> > > happens in other projects (I think CSV had a non-utf readme or release
> > note
> > > too).
> > >
> > > Site reports look great.
> > >
> > > Tested signatures from Maven and from dist area, found no issues.
> > >
> > > [x] +1 Release these artifacts (if the README issue is not a blocker)
> > >
> > > Thanks!
> > > -Bruno
> > >
> > > On Tue, 21 Jun 2022 at 16:34, Matt Juntunen 
> > > wrote:
> > >
> > > > We have fixed quite a few bugs and added some significant enhancements
> > > > since Apache Commons Configuration 2.7 was released, so I would like
> > > > to release Apache Commons Configuration 2.8.
> > > >
> > > > Apache Commons Configuration 2.8 RC1 is available for review here:
> > > >
> > https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-RC1
> > > > (svn revision 55235)
> > > >
> > > > The Git tag commons-configuration-2.8-RC1 commit for this RC is
> > > > 01e1b40769f6dd5046c74f38c4c59cf4af5e37a1 which you can browse here:
> > > >
> > > >
> > https://gitbox.apache.org/repos/asf?p=commons-configuration.git;a=commit;h=01e1b40769f6dd5046c74f38c4c59cf4af5e37a1
> > > > You may checkout this tag using:
> > > > git clone
> > > > https://gitbox.apache.org/repos/asf/commons-configuration.git
> > > > --branch
> > > > <https://gitbox.apache.org/repos/asf/commons-configuration.git--branch
> > >
> > > > commons-configuration-2.8-RC1 commons-configuration-2.8-RC1
> > > >
> > > > Maven artifacts are here:
> > > >
> > > >
> > https://repository.apache.org/content/repositories/orgapachecommons-1589/org/apache/commons/commons-configuration2/2.8/
> > > >
> > > > These are the artifacts and their hashes:
> > > >
> > > >
> > > >
> > commons-configuration2-2.8.jar=c54782ba1d6340ccf0e136c66281af7bfcf3a78235f4a2461b50a88351a6da4f463cb19ca49afb25ff82712c4f4f14985c9f960ea65213deb1ca5a9719dead38
> > > >
> > > >
> > commons-configuration2-2.8-sources.jar=1e277840f25d6a89b8f9168b5dd174093db38807b13e080aa47d26ff35602e4f5e4d6cf8bece6780af6791befd2204ce25710a8cd8eea62eabe3b554ea96e28c
> > > >
> > > >
> > commons-configuration2-2.8-tests.jar=e0ffd6379863426f8b3237dd3ee64f7345c8d2876a34b736ba5f653af1e7cd99a8a3825938c60f842599f0a43922bbb32d13ea7f0c624b8dce25edf0150c6496
> > > >
> > > >
> > commons-configuration2-2.8-test-sources.jar=f8c88936f415ab8357c96a73f9cb318e805b6a2ae47a9de9b3176c68b1fc1f4ca8880baf

[VOTE] Release Apache Commons Configuration 2.8 based on RC2

[Matt Juntunen]

We have fixed quite a few bugs and added some significant enhancements
since Apache Commons Configuration 2.7 was released, so I would like
to release Apache Commons Configuration 2.8.

Apache Commons Configuration 2.8 RC2 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-RC2
(svn revision 55251)

The Git tag commons-configuration-2.8-RC2 commit for this RC is
f540433112b9a93c26c43277c3ec7a3d40565115 which you can browse here:

https://gitbox.apache.org/repos/asf?p=commons-configuration.git;a=commit;h=f540433112b9a93c26c43277c3ec7a3d40565115
You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-configuration.git
--branch commons-configuration-2.8-RC2 commons-configuration-2.8-RC2

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1590/org/apache/commons/commons-configuration2/2.8/

These are the artifacts and their hashes:

#Release SHA-512s
#Tue Jun 21 23:27:23 EDT 2022
commons-configuration2-2.8-bin.tar.gz=b3f4628ecf3fc52feaf68ca13d0518d0ff5de8bea690a3fa625b91f2ffee9ef0fe1c575743d71bd035ba5d1c0be47a668ec1b28fb1953998f6723cecb8b59a38
commons-configuration2-2.8-bin.zip=86dc5ee9d7581b6c0b2f2807fb4f2179eec0dc4dfdb1246ffd9054a64e4511b534a4be015946403f0d0519362029cef2d4d89c684d38eaa4bd1e6af8d8b8b3a9
commons-configuration2-2.8-javadoc.jar=91dc9721ebea0345175d02b2d8e4bf08a255034549527edbecd382771540d85ca2423f22a4bc260d42ac33e9c3bd6b36a5fb7713b4919b58a0c06d9661285b0d
commons-configuration2-2.8-sources.jar=85e4f25fc9a0682bd3376de2741b48bfb6b77e98795a107c818c0bb51578cde8dd60a5e38177a6ce2a73bc4a1b9f925720321f7320fef0173c6f26c0a303bb55
commons-configuration2-2.8-src.tar.gz=924be9a8c0fd5f5a03d9ccd14a0bf79b83323f424fc4580084e807a5f7f242d40146cbdcd34d8d3a0098aeebe3040f77089230176ef737d649666152f2bda6ea
commons-configuration2-2.8-src.zip=e6695471c21e0c885b3ad5b0e0ff65a69a65cbc82a7c96d0406342f81b2efb8185b7008dfd7d49603ca96ea44761bb681aacfd997bbbae742ad922d58173305a
commons-configuration2-2.8-test-sources.jar=d203e063ec6b7ea16688c9015f10cf41bb3c592e990e214f6f808a20f19efe5973b3d30f4b939d571a8f4c1c2094d52c77733b59d0e7cdf412d27133fac7c7d9
commons-configuration2-2.8-tests.jar=6878c163de212e0617650ecbcd68887db1fc0c29f596ca773598b4ef7314e7062f4671208b8360d6ec2ca8f8408c75763912bcc545903e440fd77a6086af5c49



I have tested this with ***'mvn clean install site'*** using:
***
Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: /home/matt/tools/maven/apache-maven-3.8.4
Java version: 1.8.0_322, vendor: Temurin, runtime:
/home/matt/lang/java/jdk8u322-b06/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.17.12-300.fc36.x86_64", arch: "amd64",
family: "unix"

Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: /home/matt/tools/maven/apache-maven-3.8.4
Java version: 11.0.14.1, vendor: Eclipse Adoptium, runtime:
/home/matt/lang/java/jdk-11.0.14.1+1
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.17.12-300.fc36.x86_64", arch: "amd64",
family: "unix"
***

Details of changes since 2.7 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-RC2/RELEASE-NOTES.txt

https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-RC2/site/changes-report.html

Site:

https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-RC2/site/index.html
(note some *relative* links are broken and the 2.8 directories are
not yet created - these will be OK once the site is deployed.)

JApiCmp Report (compared to 2.7):

https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-RC2/site/japicmp.html

RAT Report:

https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-RC2/site/rat-report.html

KEYS:
  https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 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
==

These guidelines are NOT complete.

Requirements: Git, Java, Maven.

You can validate a release from a release candidate (RC) tag as follows.

1) Clone and checkout the RC tag

git clone https://gitbox.apache.org/repos/asf/commons-configuration.git
--branch commons-configuration-2.8-RC2 commons-configuration-2.8-RC2
cd commons-configuration-2.8-RC2

2) Check Apache licenses

This step is not required if the site includes a RAT report page which
you then must check.

mvn apache-rat:check

3) Check binary compatibility

Older components still use Apache Clirr:

This s

[CANCELLED] [VOTE] Release Apache Commons Configuration 2.8 based on RC1

[Matt Juntunen]

Thanks, Bruno! I'm going to go ahead and cancel this vote so I can fix
the README. I also noticed some inconsistency in the naming of the
version. In some places I called it 2.8.0 and in others 2.8. I'm going
to standardize on the shorter "2.8". RC2 should be out soon.

Regards,
Matt J

On Tue, Jun 21, 2022 at 1:30 AM Bruno Kinoshita  wrote:
>
> Hi Matt,
>
> Inspected NOTICE, LICENSE, RELEASE-NOTES, and found no issues. Checked out
> the tag, and `mvn clean test install site` passed with no errors.
>
> The README is still showing 2.7 in the download instructions. I **think**
> one of the preparation steps uses a release-plugin goal that re-generates
> this file with the correct version, but I could be wrong. Not sure if it's
> a blocker?
>
> Another thing that I noticed, but probably just nit-picking; opening a zip
> and a tar.gz file from dist/source folders each, and opening each file on
> Ubuntu LTS, I think not all files are UTF-8 encoded. The RELEASE-NOTES.txt
> fails to open on my Mousepad editor. It pops up an error dialogue that lets
> me try to guess the encoding to open it. Not an issue for me as I think it
> happens in other projects (I think CSV had a non-utf readme or release note
> too).
>
> Site reports look great.
>
> Tested signatures from Maven and from dist area, found no issues.
>
> [x] +1 Release these artifacts (if the README issue is not a blocker)
>
> Thanks!
> -Bruno
>
> On Tue, 21 Jun 2022 at 16:34, Matt Juntunen 
> wrote:
>
> > We have fixed quite a few bugs and added some significant enhancements
> > since Apache Commons Configuration 2.7 was released, so I would like
> > to release Apache Commons Configuration 2.8.
> >
> > Apache Commons Configuration 2.8 RC1 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-RC1
> > (svn revision 55235)
> >
> > The Git tag commons-configuration-2.8-RC1 commit for this RC is
> > 01e1b40769f6dd5046c74f38c4c59cf4af5e37a1 which you can browse here:
> >
> > https://gitbox.apache.org/repos/asf?p=commons-configuration.git;a=commit;h=01e1b40769f6dd5046c74f38c4c59cf4af5e37a1
> > You may checkout this tag using:
> > git clone
> > https://gitbox.apache.org/repos/asf/commons-configuration.git
> > --branch
> > <https://gitbox.apache.org/repos/asf/commons-configuration.git--branch>
> > commons-configuration-2.8-RC1 commons-configuration-2.8-RC1
> >
> > Maven artifacts are here:
> >
> > https://repository.apache.org/content/repositories/orgapachecommons-1589/org/apache/commons/commons-configuration2/2.8/
> >
> > These are the artifacts and their hashes:
> >
> >
> > commons-configuration2-2.8.jar=c54782ba1d6340ccf0e136c66281af7bfcf3a78235f4a2461b50a88351a6da4f463cb19ca49afb25ff82712c4f4f14985c9f960ea65213deb1ca5a9719dead38
> >
> > commons-configuration2-2.8-sources.jar=1e277840f25d6a89b8f9168b5dd174093db38807b13e080aa47d26ff35602e4f5e4d6cf8bece6780af6791befd2204ce25710a8cd8eea62eabe3b554ea96e28c
> >
> > commons-configuration2-2.8-tests.jar=e0ffd6379863426f8b3237dd3ee64f7345c8d2876a34b736ba5f653af1e7cd99a8a3825938c60f842599f0a43922bbb32d13ea7f0c624b8dce25edf0150c6496
> >
> > commons-configuration2-2.8-test-sources.jar=f8c88936f415ab8357c96a73f9cb318e805b6a2ae47a9de9b3176c68b1fc1f4ca8880baf9045381a29af3d858be1c3b38b9f7f9bafd700f648004b591327dc1d
> >
> > commons-configuration2-2.8-bin.tar.gz=061227c898cf9094e30feebcf71d2811eecb01951793f30a6afca4f11075e5789231956b3d92b2caa5d65a24aa835026527b7d8b7dc81b1743306a48cae67ce4
> >
> > commons-configuration2-2.8-bin.zip=47a05cf9bcfee4e5f96f7d23af463bbf56e3d044ba1ea5faaeddb34f7056ca6590e15c83738a79a46c5d5d22885d5bac7dd3930a69d21b6a05c6645f0bcc383e
> >
> > commons-configuration2-2.8-src.tar.gz=eed2b99ebba4320799f8a11fde59c180022fd93f4c7b2c597398929368c92cce6828b163976c47629a0edf8fbc0e86be5cdf3e5f01cc734dd08f716038df026f
> >
> > commons-configuration2-2.8-src.zip=321365d65479889d16e27db4e03c52cfd8a4241b0a6ef2fe1f39d07f5beed4d5d9fb09d4101de77769ef634b2f9bda46a9ba4baa706540de42605c8c1e401c8f
> >
> > I have tested this with 'mvn clean install site' using:
> > ***
> > Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
> > Maven home: /home/matt/tools/maven/apache-maven-3.8.4
> > Java version: 1.8.0_322, vendor: Temurin, runtime:
> > /home/matt/lang/java/jdk8u322-b06/jre
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "linux", version: "5.17.12-300.fc36.x86_64", arch: "amd64",
> > family: "unix"
> > ***
> >
> > Details of changes since 2.7 are in the release notes:
> >

[VOTE] Release Apache Commons Configuration 2.8 based on RC1

[Matt Juntunen]

We have fixed quite a few bugs and added some significant enhancements
since Apache Commons Configuration 2.7 was released, so I would like
to release Apache Commons Configuration 2.8.

Apache Commons Configuration 2.8 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-RC1
(svn revision 55235)

The Git tag commons-configuration-2.8-RC1 commit for this RC is
01e1b40769f6dd5046c74f38c4c59cf4af5e37a1 which you can browse here:

https://gitbox.apache.org/repos/asf?p=commons-configuration.git;a=commit;h=01e1b40769f6dd5046c74f38c4c59cf4af5e37a1
You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-configuration.git
--branch commons-configuration-2.8-RC1 commons-configuration-2.8-RC1

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1589/org/apache/commons/commons-configuration2/2.8/

These are the artifacts and their hashes:

commons-configuration2-2.8.jar=c54782ba1d6340ccf0e136c66281af7bfcf3a78235f4a2461b50a88351a6da4f463cb19ca49afb25ff82712c4f4f14985c9f960ea65213deb1ca5a9719dead38
commons-configuration2-2.8-sources.jar=1e277840f25d6a89b8f9168b5dd174093db38807b13e080aa47d26ff35602e4f5e4d6cf8bece6780af6791befd2204ce25710a8cd8eea62eabe3b554ea96e28c
commons-configuration2-2.8-tests.jar=e0ffd6379863426f8b3237dd3ee64f7345c8d2876a34b736ba5f653af1e7cd99a8a3825938c60f842599f0a43922bbb32d13ea7f0c624b8dce25edf0150c6496
commons-configuration2-2.8-test-sources.jar=f8c88936f415ab8357c96a73f9cb318e805b6a2ae47a9de9b3176c68b1fc1f4ca8880baf9045381a29af3d858be1c3b38b9f7f9bafd700f648004b591327dc1d
commons-configuration2-2.8-bin.tar.gz=061227c898cf9094e30feebcf71d2811eecb01951793f30a6afca4f11075e5789231956b3d92b2caa5d65a24aa835026527b7d8b7dc81b1743306a48cae67ce4
commons-configuration2-2.8-bin.zip=47a05cf9bcfee4e5f96f7d23af463bbf56e3d044ba1ea5faaeddb34f7056ca6590e15c83738a79a46c5d5d22885d5bac7dd3930a69d21b6a05c6645f0bcc383e
commons-configuration2-2.8-src.tar.gz=eed2b99ebba4320799f8a11fde59c180022fd93f4c7b2c597398929368c92cce6828b163976c47629a0edf8fbc0e86be5cdf3e5f01cc734dd08f716038df026f
commons-configuration2-2.8-src.zip=321365d65479889d16e27db4e03c52cfd8a4241b0a6ef2fe1f39d07f5beed4d5d9fb09d4101de77769ef634b2f9bda46a9ba4baa706540de42605c8c1e401c8f

I have tested this with 'mvn clean install site' using:
***
Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: /home/matt/tools/maven/apache-maven-3.8.4
Java version: 1.8.0_322, vendor: Temurin, runtime:
/home/matt/lang/java/jdk8u322-b06/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.17.12-300.fc36.x86_64", arch: "amd64",
family: "unix"
***

Details of changes since 2.7 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-RC1/RELEASE-NOTES.txt

https://home.apache.org/~mattjuntunen/commons-configuration-2.8-rc1-site/changes-report.html

Site:

https://home.apache.org/~mattjuntunen/commons-configuration-2.8-rc1-site/index.html
(note some *relative* links are broken and the 2.8 directories are
not yet created - these will be OK once the site is deployed.)

JApiCmp Report (compared to 2.7):

https://home.apache.org/~mattjuntunen/commons-configuration-2.8-rc1-site/japicmp.html

RAT Report:

https://home.apache.org/~mattjuntunen/commons-configuration-2.8-rc1-site/rat-report.html

KEYS:
  https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 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
==

These guidelines are NOT complete.

Requirements: Git, Java, Maven.

You can validate a release from a release candidate (RC) tag as follows.

1) Clone and checkout the RC tag

git clone https://gitbox.apache.org/repos/asf/commons-configuration.git
--branch commons-configuration-2.8-RC1 commons-configuration-2.8-RC1
cd commons-configuration-2.8-RC1

2) Check Apache licenses

This step is not required if the site includes a RAT report page which
you then must check.

mvn apache-rat:check

3) Check binary compatibility

Older components still use Apache Clirr:

This step is not required if the site includes a Clirr report page
which you then must check.

mvn clirr:check

Newer components use JApiCmp with the japicmp Maven Profile:

This step is not required if the site includes a JApiCmp report page
which you then must check.

mvn install -DskipTests -P japicmp japicmp:cmp

4) Build the package

mvn -V clean package

You can record the Maven and Java version produced by -V in your VOTE reply.
To gather OS infor

Re: [commons-configuration] 02/02: updating release docs

[Matt Juntunen]

Sounds good. I've switched branches.
-Matt J

On Mon, Jun 20, 2022 at 10:23 AM Gary Gregory  wrote:
>
> There is already a branch called "release". I think that using one branch
> per release is just clutter IMO.
>
> Gary
>
> On Sun, Jun 19, 2022, 23:13  wrote:
>
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > mattjuntunen pushed a commit to branch 2.8.0-release
> > in repository
> > https://gitbox.apache.org/repos/asf/commons-configuration.git
> >
> > commit 6434507226c639a41d45af3be26197f8e04922ec
> > Author: Matt Juntunen 
> > AuthorDate: Sun Jun 19 23:12:36 2022 -0400
> >
> > updating release docs
> > ---
> >  RELEASE-NOTES.txt| 126 +++
> >  src/changes/changes.xml  |   2 +-
> >  src/site/xdoc/building.xml   |   4 +-
> >  src/site/xdoc/download_configuration.xml | 264
> > +++
> >  4 files changed, 260 insertions(+), 136 deletions(-)
> >
> > diff --git a/RELEASE-NOTES.txt b/RELEASE-NOTES.txt
> > index c759d1d2..706f09fe 100644
> > --- a/RELEASE-NOTES.txt
> > +++ b/RELEASE-NOTES.txt
> > @@ -1,3 +1,127 @@
> > +Apache Commons Configuration
> > +Version 2.8.0
> > +Release Notes
> > +
> > +
> > +INTRODUCTION:
> > +=
> > +
> > +This document contains the release notes for this version of the Commons
> > +Configuration component. It describes the changes since the previous
> > version.
> > +The Commons Configuration software library provides a generic
> > configuration
> > +interface which enables an application to read configuration data from a
> > variety
> > +of sources.
> > +
> > +Tools to assist in the reading of configuration/preferences files in
> > +various formats
> > +
> > +Minor release with new features and updated dependencies.
> > +
> > +Changes in this version include:
> > +
> > +New features:
> > +o Implement Iterable in ImmutableNode #74. Thanks to
> > SethiPandi.
> > +o Add
> > PropertiesConfigurationLayout.getBlankLinesBefore() and deprecate
> > getBlancLinesBefore().
> > +  Thanks to Gary Gregory.
> > +o Add
> > PropertiesConfigurationLayout.setBlankLinesBefore() and deprecate
> > setBlancLinesBefore().
> > +  Thanks to Gary Gregory.
> > +o Add
> > PropertiesConfigurationLayout.PropertyLayoutData.getBlankLines() and
> > deprecate
> > +  getBlancLines(). Thanks to Gary Gregory.
> > +o Add
> > PropertiesConfigurationLayout.PropertyLayoutData.setBlankLines() and
> > deprecate
> > +  setBlancLines(). Thanks to Gary Gregory.
> > +o CONFIGURATION-789:  Add ImmutableConfiguration.getEnum() methods.
> > Thanks to Gary Gregory.
> > +o CONFIGURATION-789:  Add ImmutableConfiguration.getDuration() methods.
> > Thanks to Gary Gregory.
> > +
> > +Fixed Bugs:
> > +o CONFIGURATION-753:  Make interpolation of collections and arrays in
> > ConfigurationInterpolator consistent with
> > +  behavior of DefaultConversionHandler. Add
> > ConfigurationInterpolator.setStringConverter to
> > +  allow customized string conversion behavior.
> > +o CONFIGURATION-795:  Computation of blank lines after header comment
> > #82. Thanks to dpeger.
> > +o CONFIGURATION-801:  Remove redundant initializer #110. Thanks to Arturo
> > Bernal.
> > +o CONFIGURATION-802:  Use final #111. Thanks to Arturo Bernal.
> > +o CONFIGURATION-803:  Java 8 lambda improvements and more #112. Thanks to
> > Arturo Bernal.
> > +o CONFIGURATION-804:  Redundant local variable #113. Thanks to Arturo
> > Bernal.
> > +o CONFIGURATION-805:  Use try with resource #114. Thanks to Arturo Bernal.
> > +o CONFIGURATION-805:  [Javadoc] Specify that typed getList returns null
> > for missing key #100. Thanks to
> > +      Roman Zaynetdinov.
> > +o Mention EnvironmentConfiguration in the list of
> > configuration sources #45. Thanks to
> > +  Oliver B. Fischer.
> > +o CONFIGURATION-808:  DefaultListDelimiterHandler.escapeList working only
> > for List>String< #137. Thanks to cigaly.
> > +o Use final #141. Thanks to Arturo Bernal.
> > +o  

Re: [commons-configuration] branch master updated: fixing binary incompatibilities with v2.7

[Matt Juntunen]

Hello,

Thank you all for your feedback. What I'm hearing here is that binary
compatibility is vital between releases but source compatibility can
be changed with proper documentation and notifications. This is good
to know. For this release, I do not see a compelling reason to break
source compatibility. We can easily include the changes in the next
release, accompanied with a Jira issue to increase the visibility of
the updates.

Regards,
Matt J

On Mon, Jun 20, 2022 at 10:34 AM sebb  wrote:
>
> On Mon, 20 Jun 2022 at 15:26, Gary Gregory  wrote:
> >
> > It is OK with me because _binary_ compatibility is what matters most and
> > that is maintained.
> >
> > If you are compiling your code against a new version of a library, then
> > changing source files is fair game IMO.
>
> I agree that binary compatibility is vital; if it is broken, this
> means a new major release and a new package/Maven coords.
> That is because it is not possible in general to fix the problems that
> binary incompatibility can cause without changing package and coords.
>
> However source incompatibilities should be fixable, but might require
> some effort.
> As such, they need to mentioned in release notes, and the level of
> change needed should be reflected in the version numbering.
> e.g. if only a recompile is needed, then a patch version bump would be
> sufficient.
> Otherwise at least a minor version bump is warranted.
>
> > Gary
> >
> > On Sun, Jun 19, 2022, 10:50 Matt Juntunen  wrote:
> >
> > > Hello,
> > >
> > > The throw clauses in question are on protected methods. If a user had
> > > overridden these and then thrown an exception, they may have to modify
> > > their source in order to compile against 2.8. Is this ok from the
> > > point of view of our backwards compatibility guarantees?
> > >
> > > Regards,
> > > Matt J
> > >
> > > On Sun, Jun 19, 2022 at 2:26 AM Gary Gregory 
> > > wrote:
> > > >
> > > > This change is incorrect, binary compatibility was NOT broken as the JLS
> > > > specifies that:
> > > >
> > > > "Changes to the throws clause of methods or constructors do not break
> > > > compatibility with pre-existing binaries; these clauses are checked only
> > > at
> > > > compile time."
> > > >
> > > > See
> > > >
> > > https://docs.oracle.com/javase/specs/jls/se8/html/jls-13.html#jls-13.4.21
> > > >
> > > > The Maven default goal runs JApiCmp which checks this.
> > > >
> > > > This free us to clean up our code.
> > > >
> > > > If a user is actually reconciling sources, then, yes, they may have to
> > > > adjust call sites, which ok. Binary compatibility is maintained.
> > > >
> > > > Gary
> > > >
> > > > On Sat, Jun 18, 2022, 23:59  wrote:
> > > >
> > > > > This is an automated email from the ASF dual-hosted git repository.
> > > > >
> > > > > mattjuntunen pushed a commit to branch master
> > > > > in repository
> > > > > https://gitbox.apache.org/repos/asf/commons-configuration.git
> > > > >
> > > > >
> > > > > The following commit(s) were added to refs/heads/master by this push:
> > > > >  new 2e39ef6b fixing binary incompatibilities with v2.7
> > > > > 2e39ef6b is described below
> > > > >
> > > > > commit 2e39ef6b3909425db1ccf6c1bb58d76f953b5f9a
> > > > > Author: Matt Juntunen 
> > > > > AuthorDate: Sat Jun 18 23:59:17 2022 -0400
> > > > >
> > > > > fixing binary incompatibilities with v2.7
> > > > > ---
> > > > >  .../apache/commons/configuration2/YAMLConfiguration.java  | 15
> > > > > ---
> > > > >  .../configuration2/builder/ConfigurationBuilderEvent.java |  2 +-
> > > > >  .../org/apache/commons/configuration2/event/Event.java|  2 +-
> > > > >  .../commons/configuration2/interpol/ConstantLookup.java   |  4 ++--
> > > > >  4 files changed, 12 insertions(+), 11 deletions(-)
> > > > >
> > > > > diff --git
> > > > >
> > > a/src/main/java/org/apache/commons/configuration2/YAMLConfiguration.java
> > > > >
> > > b/src/main/java/org/apache/commons/configuration2/YAMLConfiguration.java
> > > > > index 705c2a21..4732e3f3 100644
> > > > > ---
>

Re: [commons-configuration] branch master updated: fixing binary incompatibilities with v2.7

[Matt Juntunen]

Is someone able to confirm that the
METHOD_NO_LONGER_THROWS_CHECKED_EXCEPTION japicmp compatibility change
is something we're ok with between releases? Note that this is a
binary compatible change but not a source compatible one.

Regards,
Matt J

On Sun, Jun 19, 2022 at 10:50 AM Matt Juntunen
 wrote:
>
> Hello,
>
> The throw clauses in question are on protected methods. If a user had
> overridden these and then thrown an exception, they may have to modify
> their source in order to compile against 2.8. Is this ok from the
> point of view of our backwards compatibility guarantees?
>
> Regards,
> Matt J
>
> On Sun, Jun 19, 2022 at 2:26 AM Gary Gregory  wrote:
> >
> > This change is incorrect, binary compatibility was NOT broken as the JLS
> > specifies that:
> >
> > "Changes to the throws clause of methods or constructors do not break
> > compatibility with pre-existing binaries; these clauses are checked only at
> > compile time."
> >
> > See
> > https://docs.oracle.com/javase/specs/jls/se8/html/jls-13.html#jls-13.4.21
> >
> > The Maven default goal runs JApiCmp which checks this.
> >
> > This free us to clean up our code.
> >
> > If a user is actually reconciling sources, then, yes, they may have to
> > adjust call sites, which ok. Binary compatibility is maintained.
> >
> > Gary
> >
> > On Sat, Jun 18, 2022, 23:59  wrote:
> >
> > > This is an automated email from the ASF dual-hosted git repository.
> > >
> > > mattjuntunen pushed a commit to branch master
> > > in repository
> > > https://gitbox.apache.org/repos/asf/commons-configuration.git
> > >
> > >
> > > The following commit(s) were added to refs/heads/master by this push:
> > >  new 2e39ef6b fixing binary incompatibilities with v2.7
> > > 2e39ef6b is described below
> > >
> > > commit 2e39ef6b3909425db1ccf6c1bb58d76f953b5f9a
> > > Author: Matt Juntunen 
> > > AuthorDate: Sat Jun 18 23:59:17 2022 -0400
> > >
> > > fixing binary incompatibilities with v2.7
> > > ---
> > >  .../apache/commons/configuration2/YAMLConfiguration.java  | 15
> > > ---
> > >  .../configuration2/builder/ConfigurationBuilderEvent.java |  2 +-
> > >  .../org/apache/commons/configuration2/event/Event.java|  2 +-
> > >  .../commons/configuration2/interpol/ConstantLookup.java   |  4 ++--
> > >  4 files changed, 12 insertions(+), 11 deletions(-)
> > >
> > > diff --git
> > > a/src/main/java/org/apache/commons/configuration2/YAMLConfiguration.java
> > > b/src/main/java/org/apache/commons/configuration2/YAMLConfiguration.java
> > > index 705c2a21..4732e3f3 100644
> > > ---
> > > a/src/main/java/org/apache/commons/configuration2/YAMLConfiguration.java
> > > +++
> > > b/src/main/java/org/apache/commons/configuration2/YAMLConfiguration.java
> > > @@ -17,6 +17,12 @@
> > >
> > >  package org.apache.commons.configuration2;
> > >
> > > +import java.io.IOException;
> > > +import java.io.InputStream;
> > > +import java.io.Reader;
> > > +import java.io.Writer;
> > > +import java.util.Map;
> > > +
> > >  import org.apache.commons.configuration2.ex.ConfigurationException;
> > >  import 
> > > org.apache.commons.configuration2.ex.ConfigurationRuntimeException;
> > >  import org.apache.commons.configuration2.io.InputStreamSupport;
> > > @@ -27,12 +33,6 @@ import org.yaml.snakeyaml.Yaml;
> > >  import org.yaml.snakeyaml.constructor.Constructor;
> > >  import org.yaml.snakeyaml.representer.Representer;
> > >
> > > -import java.io.IOException;
> > > -import java.io.InputStream;
> > > -import java.io.Reader;
> > > -import java.io.Writer;
> > > -import java.util.Map;
> > > -
> > >  /**
> > >   * 
> > >   * A specialized hierarchical configuration class that is able to parse
> > > YAML documents.
> > > @@ -84,7 +84,8 @@ public class YAMLConfiguration extends
> > > AbstractYAMLBasedConfiguration implements
> > >  dump(out, options);
> > >  }
> > >
> > > -public void dump(final Writer out, final DumperOptions options) {
> > > +public void dump(final Writer out, final DumperOptions options)
> > > +throws ConfigurationException, IOException {
> > >  final Yaml yaml = new Yaml(options);
> > >
> > >  yaml.dump(constructMap(getNodeModel().g

Re: [commons-configuration] branch master updated: fixing binary incompatibilities with v2.7

[Matt Juntunen]

Hello,

The throw clauses in question are on protected methods. If a user had
overridden these and then thrown an exception, they may have to modify
their source in order to compile against 2.8. Is this ok from the
point of view of our backwards compatibility guarantees?

Regards,
Matt J

On Sun, Jun 19, 2022 at 2:26 AM Gary Gregory  wrote:
>
> This change is incorrect, binary compatibility was NOT broken as the JLS
> specifies that:
>
> "Changes to the throws clause of methods or constructors do not break
> compatibility with pre-existing binaries; these clauses are checked only at
> compile time."
>
> See
> https://docs.oracle.com/javase/specs/jls/se8/html/jls-13.html#jls-13.4.21
>
> The Maven default goal runs JApiCmp which checks this.
>
> This free us to clean up our code.
>
> If a user is actually reconciling sources, then, yes, they may have to
> adjust call sites, which ok. Binary compatibility is maintained.
>
> Gary
>
> On Sat, Jun 18, 2022, 23:59  wrote:
>
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > mattjuntunen pushed a commit to branch master
> > in repository
> > https://gitbox.apache.org/repos/asf/commons-configuration.git
> >
> >
> > The following commit(s) were added to refs/heads/master by this push:
> >  new 2e39ef6b fixing binary incompatibilities with v2.7
> > 2e39ef6b is described below
> >
> > commit 2e39ef6b3909425db1ccf6c1bb58d76f953b5f9a
> > Author: Matt Juntunen 
> > AuthorDate: Sat Jun 18 23:59:17 2022 -0400
> >
> > fixing binary incompatibilities with v2.7
> > ---
> >  .../apache/commons/configuration2/YAMLConfiguration.java  | 15
> > ---
> >  .../configuration2/builder/ConfigurationBuilderEvent.java |  2 +-
> >  .../org/apache/commons/configuration2/event/Event.java|  2 +-
> >  .../commons/configuration2/interpol/ConstantLookup.java   |  4 ++--
> >  4 files changed, 12 insertions(+), 11 deletions(-)
> >
> > diff --git
> > a/src/main/java/org/apache/commons/configuration2/YAMLConfiguration.java
> > b/src/main/java/org/apache/commons/configuration2/YAMLConfiguration.java
> > index 705c2a21..4732e3f3 100644
> > ---
> > a/src/main/java/org/apache/commons/configuration2/YAMLConfiguration.java
> > +++
> > b/src/main/java/org/apache/commons/configuration2/YAMLConfiguration.java
> > @@ -17,6 +17,12 @@
> >
> >  package org.apache.commons.configuration2;
> >
> > +import java.io.IOException;
> > +import java.io.InputStream;
> > +import java.io.Reader;
> > +import java.io.Writer;
> > +import java.util.Map;
> > +
> >  import org.apache.commons.configuration2.ex.ConfigurationException;
> >  import org.apache.commons.configuration2.ex.ConfigurationRuntimeException;
> >  import org.apache.commons.configuration2.io.InputStreamSupport;
> > @@ -27,12 +33,6 @@ import org.yaml.snakeyaml.Yaml;
> >  import org.yaml.snakeyaml.constructor.Constructor;
> >  import org.yaml.snakeyaml.representer.Representer;
> >
> > -import java.io.IOException;
> > -import java.io.InputStream;
> > -import java.io.Reader;
> > -import java.io.Writer;
> > -import java.util.Map;
> > -
> >  /**
> >   * 
> >   * A specialized hierarchical configuration class that is able to parse
> > YAML documents.
> > @@ -84,7 +84,8 @@ public class YAMLConfiguration extends
> > AbstractYAMLBasedConfiguration implements
> >  dump(out, options);
> >  }
> >
> > -public void dump(final Writer out, final DumperOptions options) {
> > +public void dump(final Writer out, final DumperOptions options)
> > +throws ConfigurationException, IOException {
> >  final Yaml yaml = new Yaml(options);
> >
> >  yaml.dump(constructMap(getNodeModel().getNodeHandler().getRootNode()),
> > out);
> >  }
> > diff --git
> > a/src/main/java/org/apache/commons/configuration2/builder/ConfigurationBuilderEvent.java
> > b/src/main/java/org/apache/commons/configuration2/builder/ConfigurationBuilderEvent.java
> > index 9f944b44..f4aa7f77 100644
> > ---
> > a/src/main/java/org/apache/commons/configuration2/builder/ConfigurationBuilderEvent.java
> > +++
> > b/src/main/java/org/apache/commons/configuration2/builder/ConfigurationBuilderEvent.java
> > @@ -33,7 +33,7 @@ import org.apache.commons.configuration2.event.EventType;
> >   */
> >  public class ConfigurationBuilderEvent extends Event {
> >
> > -private static final long serialVersionUID = 1L;
> > +private static final long seria

[configuration] preparing 2.8.0-rc1

[Matt Juntunen]

Hello,

All planned changes for commons-configuration 2.8.0 are now in master
so I am going to start preparing RC1. I haven't released this project
before so I'm hoping that I won't run into any issues and will be able
to have an RC out to vote on within the next few days.

Let me know if you have any questions or concerns.

Regards,
Matt J

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

Re: [configuration] Jakarta mailapi 2.0.1

[Matt Juntunen]

I'm glad I asked this question :-) Bruno actually submitted a PR with
support for both the old and new namespaces [1] but we decided not to
go with it since it felt like too much to support both versions of the
API. However, this discussion is making me rethink that choice. For
one, dropping support for the old API may actually require users to
update their code (as described in my initial email), effectively
breaking backwards compatibility. However, we do want to support the
newer mailapi version as well so we do not force users to use an
outdated dependency.

So, unless anyone objects, I will plan on resurrecting Bruno's PR
within the next few days and merging it in.

Regards,
Matt J


[1] https://github.com/apache/commons-configuration/pull/107

On Fri, Jun 10, 2022 at 4:32 PM Emmanuel Bourg  wrote:
>
> On 10/06/2022 22:16, Rob Spoor wrote:
> > Since reflection is used to create the instances, isn't it possible to
> > support both?
>
> +1, we should support both
>
> Emmanuel Bourg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [numbers][gsoc] GSoC 2022 - NUMBERS-186 Proposal

[Matt Juntunen]

Hello,

Good discussion here! This is great!

I lost track of what the overall goal here is while reading through
the conversation. The goal of NUMBERS-186 is to "allow operations to
be performed on lists of complex numbers". My first thought when
looking at this is "how are we going to represent lists of complex
numbers?" I don't think there is a single answer to this since the
correct format for a list of complex numbers is whatever format the
user already has them in. They could be in a file, in separate double
arrays, in a single double array (alternating real and imaginary), in
a float array, in a java.nio.Buffer, etc. So far, I haven't seen an
API that can accomodate all of these. What I would like to see us
create is an interface or abstract class like java.util.Buffer that
allows us to wrap an underlying storage mechanism with complex number
semantics. For example, if you have real and imaginary parts in two
separate arrays, you could do something like

ComplexBuffer buf =
ComplexBuffer.fromRealAndImaginaryArrays(realArr, imArr);

Similarly, with a DoubleBuffer:

ComplexBuffer buf = ComplexBuffer.fromDoubleBuffer(buf);

We can completely hide the classes implementing the wrappings here
from the public API so that things are straightforward for the user.
If we can first create a simple public API like this, then we can
safely focus on performance improvements within the private code.

Regards,
Matt J


On Sat, Jun 11, 2022 at 8:32 AM Gilles Sadowski  wrote:
>
> Hello.
>
> > [...]
> >
> > interface ComplexDoubleArray {
> > Stream stream(int start, int length);
> > }
> >
> > ComplexDoubleArray a;
> > // Will use the Java 8 ForkJoinPool.commonPool() for parallel execution
> > a.stream(start, length).parallel().forEach(x -> ComplexFunctions.conj(x,
> > x));
> >
> > class ComplexFunctions {
> > static void conj(ComplexDoubleArray in, ComplexDoubleArray out);
> > }
> >
> > [...]
>
> I have a hard time figuring out whether these bits of code are
> intended to become the application developer API...
> What data-structure(s) will be visible (from the application)?
> What will be hidden ("implementation details")?
> Do we have use-cases of non-trivial processing of N-dimensional
> cubes of complex numbers?  [I imagine that the same API should
> be able to also process cubes of real numbers (without storing the
> "0" imaginary parts).]
>
> Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [collections] Add a list/deque faster than TreeList?

[Matt Juntunen]

Hello,

I agree that this looks interesting. I personally would like to see
the following before weighing in on whether or not to include it in
commons:

1. A list of use cases where this data structure would be potentially
more performant or useful than existing data structures.
2. A set of JMH[1] benchmarks that compares this data structure to
TreeList and ArrayList (and others if needed). I see that there are
basic benchmarks already in the code, but JMH will give us much more
accurate and reproducible results. There are examples of such
benchmarks in several commons projects, e.g., commons-numbers [2] and
commons-geometry [3].

Regardless, thank you for your proposal and code, rodde. It is much appreciated.

Regards,
Matt J

[1] https://openjdk.java.net/projects/code-tools/jmh/
[2] 
https://github.com/apache/commons-numbers/tree/master/commons-numbers-examples/examples-jmh
[3] 
https://github.com/apache/commons-geometry/tree/master/commons-geometry-examples/examples-jmh


On Sat, Jun 11, 2022 at 1:25 PM Rodion Efremov  wrote:
>
> Hi Matt and community,
>
> About thread safety: I keep an int counting modifications (called
> modCount). Now, spliterator/iterator/sublist check that modCount ==
> expectedModCount, and if that is not the case, throws
> ConcurrentModificationException. Basically, it resembles the fail-fast
> behavior of ArrayList/LinkedList. In order to deal with concurrency, one
> should wrap an instance of IndexedLinkedList into
> Collections.synchronizedList(...).
>
> About Guava: they happily turned down my offer.
>
> Best regards,
> rodde
>
> la 11.6.2022 klo 19.44 Matt Sicker  kirjoitti:
>
> > Looks pretty interesting. I’ll be honest that my own data structure
> > expertise revolves around immutable persistent patterns rather than mutable
> > ones, but your class makes perfect sense as a mutable one.
> >
> > Do you have any notes on thread safety?
> >
> > While it’s neat that you’re submitting to the JDK as well, that sort of
> > process is fairly long term, so I’d imagine that Collections would be a
> > great place for it. If you’re trying to donate this to multiple projects,
> > then Eclipse also has a collections library that might like it, and Guava
> > might like it, too.
> >
> > —
> > Matt Sicker
> >
> > > On Jun 10, 2022, at 14:30, Rodion Efremov  wrote:
> > >
> > > Hi,
> > >
> > > I have this List/Deque data structure:
> > >
> > > https://github.com/coderodde/IndexedLinkedList
> > >
> > > In a versatile benchmark, it outperforms the O(log n) TreeList easily by
> > > the factor of 2. (Also, it requires less memory than TreeList.)
> > >
> > > What do you think? Does it deserve to be included in collections?
> > >
> > > Best regards,
> > > rodde
> >

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

[configuration] Jakarta mailapi 2.0.1

[Matt Juntunen]

Hello,

We are slowly getting closer to a 2.8.0 release for
commons-configuration. One remaining item on the list is a PR [1] for
bumping the com.sun.mail:mailapi optional dependency from 1.6.7 to
2.0.1. I'd like to get community input on this change since it
involves a package name change in the javamail api (javax to jakarta).
This change has also been discussed recently for commons-email and
ultimately rejected in favor of backwards compatibility [2]. The
situation in configuration is a bit different, however, because
1. the mailapi dependency is optional and
2. it is not part of the public API and could be considered a
convenience type conversion.

As far as I can tell, the only impacted users would be those using the
Configuration.get(Class cls, String key) method to get a mailapi
InternetAddress object. If we go with this change, calls using the
previous mailapi InternetAddress class, such as

Configuration.get(javax.mail.internet.InternetAddress.class, key)

would begin to throw ConversionExceptions. Users would then need to
update their mailapi version and begin using

Configuration.get(jakarta.mail.internet.InternetAddress.class, key)

Is anyone opposed to this change?

Regards,
Matt J

[1] https://github.com/apache/commons-configuration/pull/185
[2] https://github.com/apache/commons-email/pull/80

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

Re: [ALL] components still using Travis

[Matt Juntunen]

+1 as well.

Thanks, Alex! I have spent quite a bit of time refreshing the Travis
build page over and over waiting for my builds to start, so this will
be a welcome change :-)

-Matt J

On Thu, May 26, 2022 at 3:55 PM Bruno Kinoshita  wrote:
>
> +1
>
> Thanks Alex!
>
> On Fri, 27 May 2022, 3:13 am Alex Herbert,  wrote:
>
> > Continuing the thread about switching Travis to GitHub actions...
> >
> > Commons RNG has been running travis and GH actions in parallel now for 6
> > weeks as an experiment.
> >
> > Some PRs have been missed by Travis. The master branch continues to be
> > built for all commits. The latest PR was built but about 12 hours after the
> > push. In comparison GH actions has been very fast, often building within a
> > few minutes.
> >
> > So Travis support is flaky for PRs and slower than GH. I propose to drop
> > travis for RNG and migrate the following multi-module math derived projects
> > to GH actions:
> >
> > - Numbers
> > - Statistics
> > - Math
> > - Geometry
> >
> > One item to note is that to obtain code coverage requires a switch from
> > coveralls to codecov. For RNG this could use a single aggregate jacoco
> > report as the multi-module project has an aggregator module for coverage
> > and javadoc reports. However the codecov documentation indicates that a
> > comma separated list of reports can be used. So as a test I will try and
> > configure this for the 11 modules we have in numbers.
> >
> > This change will require redirection of the CI build status and coverage
> > badges in the README.md page for each module.
> >
> > Alex
> >

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

Re: [configuration] 2.8.0 Release Prep

[Matt Juntunen]

Hello,

FYI, for anyone following this release preparation, there are just a
couple more issues that need to be addressed before an RC can be
created. I will send an update once we're ready to go.

Regards,
Matt J

On Tue, May 10, 2022 at 10:11 PM Gary Gregory  wrote:
>
> Hi Matt,
>
> Please hold off on an RC. I should be able to address a specific issue over
> the weekend. Contact me on the private PMC list if you have any questions.
>
> Gary
>
> On Mon, May 9, 2022, 22:50 Matt Juntunen  wrote:
>
> > Hello,
> >
> > I'm getting ready to create the commons-configuration 2.8.0 release
> > and am currently trying to clear some of the outstanding GitHub PRs.
> > Are there any out of the current set of PRs that we definitely do or
> > do not want to include in 2.8.0?
> >
> > Regards,
> > Matt J
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >

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

Re: [ANNOUNCEMENT] Apache Commons Imaging 1.0-alpha3 Released

[Matt Juntunen]

Congrats, guys! Well earned.
-Matt J


On Thu, May 19, 2022 at 7:38 AM Gary Lucas  wrote:
>
> My next step will be to update the demonstration code from the
> Gridfour software package to use the new API. I'm also going to update the
> article on Elevation GeoTIFFs and Shaded Relief Rendering
>  to
> reflect the improvements to the imaging parameters specification. Finally,
> I'm working on a new article to discuss how to access metadata from
> GeoTIFFs. So I'll be using the new Imaging library quite a bit.
>
> Gary L.
>
>
>
> On Thu, May 19, 2022 at 7:20 AM Bruno Kinoshita 
> wrote:
>
> > You are very welcome Gary! De nada :)
> >
> > And thank you for all your hard work on this release too! Have fun parsing
> > the TIFF files now. Let's stabilize the API, make any final changes to the
> > public API, and prepare the 1.0 in a few months (I'm planning the 1.0 for
> > 2022).
> >
> > If I have time in the next coming weeks I will start some experiments with
> > Imaging 1.0-alpha3 using it in the Cantaloupe IIIF server and report the
> > results here in the dev mailing list.
> >
> > Bruno
> >
> > On Thu, 19 May 2022 at 23:03, Gary Lucas  wrote:
> >
> > > Obrigado, Bruno!  I appreciate all of the careful work you put into this
> > > release.
> > >
> > > Gary
> > >
> > >
> > > On Thu, May 19, 2022 at 3:56 AM Bruno Kinoshita 
> > wrote:
> > >
> > > > The Apache Commons Team is pleased to announce the availability of
> > > > Apache Commons Imaging 1.0-alpha3.
> > > >
> > > > Apache Commons Imaging, previously known as Apache Commons Sanselan,
> > > > is a library that reads and writes a variety of image formats,
> > including
> > > > fast parsing of image info (size, color space, ICC profile, etc.) and
> > > > metadata.
> > > >
> > > > Version 1.0-alpha3 has a series of bug fixes, new features, and
> > > > improvements.
> > > > There are breaking changes since alpha2 as we are not maintaining
> > > backward
> > > > compatibility until it reaches the 1.0 release (likely the next
> > release).
> > > >
> > > > A full list of changes can be found at
> > > > https://commons.apache.org/proper/commons-imaging/changes-report.html
> > > >
> > > > Source and binary distributions are available for download from the
> > > > Apache Commons download site:
> > > >
> > > > https://commons.apache.org/proper/commons-imaging/download_imaging.cgi
> > > >
> > > > Please verify signatures using the KEYS file available at the above
> > > > location when downloading the release.
> > > >
> > > > For complete information on Commons Imaging, including
> > > > instructions on how to submit bug reports, patches, or suggestions for
> > > > improvement, see the Apache Commons Imaging website:
> > > >
> > > > https://commons.apache.org/proper/commons-imaging/
> > > >
> > > > Bruno
> > > > on behalf of the Apache Commons community
> > > >
> > >
> >

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

[configuration] CONFIGURATION-753 Interpolation Consistency

[Matt Juntunen]

Hello,

I've made a new PR [1] for CONFIGURATION-753 as part of my
preparations for the next release. I'd like to get another pair of
eyes on it if possible since it adds to the public API. The primary
cause of the issue is that DefaultConversionHandler and
ConfigurationInterpolator use different logic when determining how to
convert container objects (e.g., collections and arrays) to strings.
DefaultConversionHandler chooses the first element from the container
and ConfigurationInterpolator just calls toString on the entire
container, resulting in inconsistent string interpolation results. The
change I made is to extract the ConfigurationInterpolator string
conversion logic into a configurable "stringConverter" function that
defaults to behave similarly to DefaultConversionHandler. If this
logic is not what users want, they are free to override it.

If anyone has time to give feedback on this, it would be much
appreciated, especially since I haven't worked with configuration much
before.

Regards,
Matt J

[1] https://github.com/apache/commons-configuration/pull/181

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

Re: [VOTE] Release Apache Commons Imaging 1.0-alpha3 based on RC2

[Matt Juntunen]

Hello.

- Signatures and hashes look good on distribution and maven repo.

- Builds with "maven clean install site" from source distribution with

Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: /home/matt/tools/maven/apache-maven-3.8.4
Java version: 11.0.14.1, vendor: Eclipse Adoptium, runtime:
/home/matt/lang/java/jdk-11.0.14.1+1
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.17.4-200.fc35.x86_64", arch: "amd64",
family: "unix"

Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: /home/matt/tools/maven/apache-maven-3.8.4
Java version: 1.8.0_322, vendor: Temurin, runtime:
/home/matt/lang/java/jdk8u322-b06/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.17.4-200.fc35.x86_64", arch: "amd64",
family: "unix"

- Builds with default maven goal from git tag with

Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: /home/matt/tools/maven/apache-maven-3.8.4
Java version: 17.0.2, vendor: Eclipse Adoptium, runtime:
/home/matt/lang/java/jdk-17.0.2+8
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.17.4-200.fc35.x86_64", arch: "amd64",
family: "unix"

- NOTE: Below are some updates that should be made to the site but I
don't consider these to be blocking issues for the release.
- There are some discrepancies in the required Java version on the
site. The "Why Use Commons Imaging?" page says Java 1.5 and "Getting
Started" page says Java 1.7.
- The Roadmap page appears out of date (e.g., it discusses a plan
for moving to version 2.0).

Vote:
[x] +1 Release these artifacts

Thanks, Bruno and team!

Regards,
Matt J

On Sat, May 14, 2022 at 12:50 PM Arturo Bernal
 wrote:
>
>
> +1
>
> Testing git tag on macOS 12.3 with Java 8  and 17.
>
>
> TY
>
>
> Arturo Bernal
> arturobern...@yahoo.com
>
>
>
> > On 14 May 2022, at 16:52, Andreas Lehmkuehler  wrote:
> >
> > Hi,
> >
> > here is my +1 (non-binding as I'm not a commons PMC member)
> >
> > I've succesfully build the alpha release using
> >
> > mvn clean install site
> >
> > Apache Maven 3.6.3 (Red Hat 3.6.3-13)
> > Java version: 11.0.15, vendor: Red Hat, Inc., runtime: 
> > /usr/lib/jvm/java-11-openjdk-11.0.15.0.10-1.fc35.x86_64
> > Default locale: de_DE, platform encoding: UTF-8
> > OS name: "linux", version: "5.17.5-200.fc35.x86_64", arch: "amd64", family: 
> > "unix"
> >
> > Thanks to all who made this possible!
> >
> > Cheers
> > Andreas
> >
> >
> >
> > Am 13.05.22 um 14:02 schrieb Bruno Kinoshita:
> >> We have fixed quite a few bugs and added some significant enhancements
> >> since Apache Commons Imaging 1.0-alpha2 was released, so I would like to
> >> release Apache Commons Imaging 1.0-alpha3.
> >> Apache Commons Imaging 1.0-alpha3 RC2 is available for review here:
> >> https://dist.apache.org/repos/dist/dev/commons/imaging/1.0-alpha3-RC2
> >> (svn revision 54488)
> >> The Git tag commons-imaging-1.0-alpha3-RC2 commit for this RC is
> >> bef4caa54f8e736644f3d5bb4658d5c3c95ec70a which you can browse here:
> >> https://gitbox.apache.org/repos/asf?p=commons-imaging.git;a=commit;h=bef4caa54f8e736644f3d5bb4658d5c3c95ec70a
> >> You may checkout this tag using:
> >> git clone https://gitbox.apache.org/repos/asf/commons-imaging.git
> >> --branch commons-imaging-1.0-alpha3-RC2 commons-imaging-1.0-alpha3-RC2
> >> Maven artifacts are here:
> >> https://repository.apache.org/content/repositories/orgapachecommons-1587/org/apache/commons/commons-imaging/1.0-alpha3/
> >> These are the artifacts and their hashes:
> >> #Release SHA-512s
> >> #Fri May 13 23:32:54 NZST 2022
> >> commons-imaging-1.0-alpha3-tests.jar=6fad2edc85f4428de195e2dafe5b3cc2be19307b8b1dcc00c6ceaa92eb7767cfb4621c9a3a7c433e1486997f11f05114c04275a8129fe5f15999f1414baa9041
> >> commons-imaging-1.0-alpha3-sources.jar=5e2f5ad8c6d9b988569793e707926d40498dbc07f7404027d67ec67fa061e1aea9947f7d05a9cf60290326689c6296287055e8b9f334426ebab76620152fff1e
> >> commons-imaging-1.0-alpha3-bin.zip=bdf53a57521aea0c11c20e0884cbb68cc756ebee34f0d48319816333e600777caf04ded543a4f2560d1adef7dd2993c0cc9b4e32e3db6d024a950650222cc277
> >> commons-imaging-1.0-alpha3-src.zip=73511d7068a665471805af6a832b26fa5f2f32ea1a716c0cac9a5b3a2d47cfd2e343b35a2ae79d29fa22dc54586be274c4500d209e057a544776b8f0e77cb7cb
> >> commons-imaging-1.0-alpha3-javadoc.jar=624c8cafa60159be44392c51e515617548526fbe40b56f45d3f0ccc83f220a59145de474d6428e5ede383f536a18ccd4382c7673d0a14ba3b9d9cd82db4ffe6e
> >> commons-imaging-1.0-alpha3-test-sources.jar=a5204a827e9d5b8fa1d98967f7b416c9a1af81eb0d9009fc0159447dbdab56e18cdaaaf10ea50b0dfc941f6668f21df1c1a49df1c051dd8cda79a3e3f00c0572
> >> commons-imaging-1.0-alpha3-bin.tar.gz=877c1b28fe8fd82207d6873673e23b3ced73f09c9bd20fcfe35ff72be8480e1d0558f966fdbdd25dacef92fca02643b0cd0cdb27928914a77fad65dd47feea7d
> >> 

[configuration] 2.8.0 Release Prep

[Matt Juntunen]

Hello,

I'm getting ready to create the commons-configuration 2.8.0 release
and am currently trying to clear some of the outstanding GitHub PRs.
Are there any out of the current set of PRs that we definitely do or
do not want to include in 2.8.0?

Regards,
Matt J

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

Re: [parent][rng] japicmp binary compatibility for interface default methods

[Matt Juntunen]

Sounds reasonable to me. Are there any arguments against this change
other than the fact that it is not a japicmp default setting?

-Matt J

On Mon, May 9, 2022 at 8:59 AM Alex Herbert  wrote:
>
> I would like to change some current interface methods in Commons RNG to
> have a default implementation. This is detected as not allowed by the
> current japicmp settings in commons parent. I think the settings should be
> updated.
>
> The default settings for japicmp state that default methods introduced into
> an interface break binary (and source) compatibility. This is entry
> METHOD_NEW_DEFAULT in the japicmp-maven-plugin documentation here [1]. This
> is not correct (and is the reason for default methods in interfaces) and
> was fixed in commons parent in commit d5d3a1b [2].
>
> Changing an existing method in an interface to have a default
> implementation is also listed as not compatible in japicmp
> (entry METHOD_ABSTRACT_NOW_DEFAULT). However I cannot prove that this does
> break binary (or functional) compatibility. I've tested execution of
> classes compiled against an old version of the interface when the classpath
> includes a new version with a default implementation. It all runs as
> expected, i.e. existing implementations of interface methods are invoked.
>
> I ran some other tools listed on the japicmp page against the code where
> one interface method has been changed from abstract to default.
>
> Java API Compliance Checker [3]
> revapi [4]
>
> If I do something wrong such as removing an interface method then the tools
> list compatibility as broken. If I add a default implementation to an
> interface method both these tools do not raise an error.
>
> The change is reported by the Java API Compliance Checker and is listed as
> compatible. However I cannot get revapi to report that the interface
> methods now have a default implementation. The revapi check is Method Now
> Default and is listed as a transparent change [5]. The omission from the
> report may be due to some settings I did not find in the maven plugin.
>
> I suggest updating commons parent to allow METHOD_ABSTRACT_NOW_DEFAULT to
> be a non-breaking change.
>
> Alex
>
> [1] https://siom79.github.io/japicmp/MavenPlugin.html
> [2]
> https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=d5d3a1bcb03cf3c2bb50e66786ce73e6779fa62d
> [3] http://ispras.linuxbase.org/index.php/Java_API_Compliance_Checker
> [4] https://revapi.org/revapi-site/main/index.html
> [5]
> https://revapi.org/revapi-java/0.26.1/differences.html#java.method.nowDefault

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

Re: [compress] broken test or main for TarFileTest.testDirectoryWithLongNameEndsWithSlash()

[Matt Juntunen]

Hello,

I've created a PR with a fix for that test. However, I'm not familiar
enough with the tar format to know if this is all that's needed or if
there is a deeper issue that needs to be addressed.

Regards,
Matt J

On Thu, May 5, 2022 at 8:41 PM Gary Gregory  wrote:
>
> Hi All,
>
> I discovered earlier today that most tests (expect pack200) tests were
> being skipped when running the Maven test goal. This is likely due to
> a combination of updating commons-parent from 52 to 53 and porting
> from JUnit 4 to 5 which was not checked properly.
>
> I fixed all that but there remains ONE failing test on Linux and
> macOS: TarFileTest.testDirectoryWithLongNameEndsWithSlash().
>
> The whole build is green on Windows as you can see on GitHub Actions.
>
> Any help in fixing this last test is appreciated.
>
> TY,
> Gary
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

[geometry] BoundsXD Linecast PR

[Matt Juntunen]

Hello,

I've created a PR[1] for GEOMETRY-147, adding line/ray intersection
methods to the BoundsXD classes, which are axis-aligned bounding
boxes. I'm picturing this being useful when raycasting against data
structures that use these bounding boxes, such as quadtrees, octrees,
and bounding volume hierarchies. Feedback is welcome. If I don't
receive any objections, I plan on merging this within the next few
days.

Regards,
Matt J

[1] https://github.com/apache/commons-geometry/pull/196

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

Re: New component proposal: commons-plugins

[Matt Juntunen]

Hi Matt,

This is quite timely since I've spent the past week researching
frameworks to modularize a monolithic application at my day job into
separate components/plugins. Everything I've looked at so far is
larger and more complicated than I need (e.g. OSGi, Spring, etc) so I
was seriously considering writing my own, perhaps based on select
components from the Plexus project [1]. I would be interested in this
project if it could do the following:
- provide a standardized plugin packaging format;
- provide standardized configuration mechanisms;
- handle plugin discovery and enumeration;
- handle service discovery, enumeration, and dependency injection;
- handle class loading and resolution of plugin dependencies (e.g. a
plugin that depends on a different version of commons-lang than
another plugin); and
- provide plugin lifecycle methods.

It would also be great if the project was compatible with different
frameworks. For example, if the dependency injection functionality
could be swapped out for Spring if needed.

I haven't totally completed my research so I'm not sure if there is
actually an existing framework out there that satisfies the above
requirements. If not, I would be willing to help out to get this
implemented, regardless of whether it ends up in commons or not.

One more thought: I think it would be equally important (if not more
so) to define the non-goals of this potential project as the goals. Do
you have an idea of what those would be?

Regards,
Matt J

[1] https://codehaus-plexus.github.io/

On Sun, Apr 3, 2022 at 6:24 AM Gary Gregory  wrote:
>
> Should this be in Commons Configuration?
>
> Gary
>
> On Sat, Apr 2, 2022, 15:33 Matt Sicker  wrote:
>
> > Hi all, I’ve got a proposal for a new Commons component that I’d like to
> > get feedback on. Essentially, I’d like to propose the creation of a Commons
> > Plugins component inspired by the plugin system developed for Log4j 3.x
> > [0]. This library would be a lightweight dependency injection and
> > configuration library where developers create pluggable classes that can be
> > referenced through plugin names via the configuration file (or
> > configuration source in general). In contrast with more typical dependency
> > injection frameworks like Spring and Guice, this library is for
> > applications where pluggable implementations of things is desired.
> > Developing a plugin system on top of DI frameworks is not a very
> > standardized domain, and each project ends up reinventing this from scratch
> > over time.
> >
> > Some existing material on how the Log4j plugin and configuration system
> > works that I’d adapt from to form the basis for this component include:
> > -
> > https://github.com/apache/logging-log4j2/blob/master/src/site/asciidoc/manual/dependencyinjection.adoc
> > <
> > https://github.com/apache/logging-log4j2/blob/master/src/site/asciidoc/manual/dependencyinjection.adoc
> > >
> > -
> > https://github.com/apache/logging-log4j2/blob/master/src/site/asciidoc/manual/plugins.adoc
> > <
> > https://github.com/apache/logging-log4j2/blob/master/src/site/asciidoc/manual/plugins.adoc
> > >
> >
> > The general goal of this library is to make it so that applications can
> > provide better configuration DSLs for their plugin components. As both a
> > developer and user, I absolutely despise configuring complex applications
> > with properties files, and YAML variants of properties aren’t that much
> > better. If there was a common plugin library we could reuse, then perhaps
> > more applications would support a better configuration system. This could
> > also provide a nice place for tooling integration similar to how JUnit is
> > supported by IDEs and other tools.
> >
> > What do you think? Should this start in the Sandbox? Is anyone interested
> > in working on or using this?
> >
> > [0]: https://github.com/apache/logging-log4j2/tree/master/log4j-plugins <
> > https://github.com/apache/logging-log4j2/tree/master/log4j-plugins>
> >
> > —
> > Matt Sicker
> >
> >

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

Re: [ALL] components still using Travis

[Matt Juntunen]

Hi Sebb,

Yep, geometry is still using Travis. I've never used GitHub Actions so
I'm not sure what it's capable of. Are there any specific features it
provides that are driving the migration to it? Or is it more a matter
of community preference? Either way is fine, I'm just curious.

Regards,
Matt J

On Tue, Mar 29, 2022 at 7:22 AM sebb  wrote:
>
> It looks like there is a general move to switch from Travis to GitHub Actions.
> AFAICT the following components are still using Travis:
>
> geometry
> jelly
> jxpath
> math
> numbers
> rng
> weaver
>
> Do we need to move these as well?
>
> BTW, emails from GHA runs can now be directed to project mailing
> lists, which is great (*)
> See: https://s.apache.org/asfyaml-gha
>
> e.g. update .asf.yaml to include:
> notifications:
> ...
>   jobs: notificati...@commons.apache.org
>
> Sebb.
> (*) Travis always had this, but recently switched to a new email
> system which means all such mails have to be moderated.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: Re: [geometry] PointMap and PointSet

[Matt Juntunen]

Hello,

This kind of API sounds useful but not directly related to the
PointMap/Set types. As you mentioned, it seems like the API would most
likely use PointMap/Set internally. I believe the next step should be
to create a JIRA issue and figure out the details there.

Since it sounds like there are no objections to the current
PointMap/Set PR, I'm going to go ahead and merge it in and then
continue on with the closest point/farthest point API (GEOMETRY-146).

Regards,
Matt

On Wed, Mar 23, 2022 at 12:58 PM Gilles Sadowski  wrote:
>
> Hi.
>
> Le mer. 23 mars 2022 à 03:27, Matt Juntunen
>  a écrit :
> >
> > Gilles,
> >
> > > Say, for example, that "V" holds a single (floating-point) value.  We
> > > insert entries
> > >  map.put(x, 2);
> > >  map.put(y, 8);
> > > assuming that "x" and "y" and just barely different, according to the
> > > chosen "precision context".  Then:
> > > z = (x + y) / 2; // Pseudo-code.
> >  > m = map.get(z);
> > > Does "m" equal "2" or "8", depending on whether "z" is (however
> > > slightly) closer to either "x" or "y"?  Or is it "5" (interpolated value)?
> >
> > It would be either 2 or 8. In the current implementations the first
> > matching entry is returned and since entries are typically searched
> > low to high, the entry corresponding to the lower of the two keys
> > would be returned. However, I do not consider this "lowest match wins"
> > behavior to be part of the public API since it depends on the
> > implementation details.
>
> For sure, any functionality must start from some low-level data
> structure with some prescribed behaviour.  Here, we assume that
> the "mechanism" returns "2" or "8" (depending on the "details").
>
> My point is rather that the "cloud of points" abstraction seems to
> require a higher-level API (for which "PointMap" would, in turn,
> be an "implementation detail" too).
> Within that abstraction, querying the value at location between
> "x" and "y" would return some interpolation (i.e. any user-defined
> "combiner") of the data stored within a given "radius" of the
> queried location.
> This would make more sense (IMO) than the application having
> to deal with a result ("2" or "8") that is implementation-dependent:
> Such an additional API layer would allow the caller to specify the
> "combiner" as, for example, "the average of the values", the result
> would then be univocally defined ("5").
> [Obviously, when specifying a radius smaller than the "precision
> context", the behaviour would be identical to a direct query to the
> underlying "PointMap".]
>
> >
> > > But is it the right behaviour in all cases, or should there be a
> > > "replacement policy" (to apply whenever points are already stored
> > > within the "precision context" neighbourhood)?
> >
> > This seems to me like additional logic that could be built on top of
> > PointMap/Set, probably using the distance query methods in
> > GEOMETRY-146.
>
> Indeed; my question aimed at pointing to the importance of providing
> such an API.
>
> > Do you have a use case in mind here?
>
> In 2D: create an image (i.e. rectangular regular grid) that represents
> the (interpolated) data associated with the (scattered) points.
>
> Another (unrelated to the above discussion) feature: Allow different
> precision contexts in different regions of the space (cf. [1]).
>
> Best,
> Gilles
>
> [1] https://en.wikipedia.org/wiki/Unstructured_grid
>
> >
> > Regards,
> > Matt
> >
> > On Tue, Mar 22, 2022 at 1:05 PM Gilles Sadowski  
> > wrote:
> > >
> > > Le mar. 22 mars 2022 à 14:46, Matt Juntunen
> > >  a écrit :
> > > >
> > > > Hello,
> > > >
> > > > Unless there are any other comments on the PR, I'm going to plan on
> > > > merging it into master within the next couple of days.
> > > >
> > >
> > > Thanks for providing this new functionality.
> > >
> > > Do you envision that [Geometry] will also provide ways to manipulate
> > > data stored in the map (the "V" in e.g. "PointMap")?
> > >
> > > Say, for example, that "V" holds a single (floating-point) value.  We
> > > insert entries
> > >   map.put(x, 2);
> > >   m

Re: Re: [geometry] PointMap and PointSet

[Matt Juntunen]

Gilles,

> Say, for example, that "V" holds a single (floating-point) value.  We
> insert entries
>  map.put(x, 2);
>  map.put(y, 8);
> assuming that "x" and "y" and just barely different, according to the
> chosen "precision context".  Then:
> z = (x + y) / 2; // Pseudo-code.
 > m = map.get(z);
> Does "m" equal "2" or "8", depending on whether "z" is (however
> slightly) closer to either "x" or "y"?  Or is it "5" (interpolated value)?

It would be either 2 or 8. In the current implementations the first
matching entry is returned and since entries are typically searched
low to high, the entry corresponding to the lower of the two keys
would be returned. However, I do not consider this "lowest match wins"
behavior to be part of the public API since it depends on the
implementation details.

> But is it the right behaviour in all cases, or should there be a
> "replacement policy" (to apply whenever points are already stored
> within the "precision context" neighbourhood)?

This seems to me like additional logic that could be built on top of
PointMap/Set, probably using the distance query methods in
GEOMETRY-146. Do you have a use case in mind here?

Regards,
Matt

On Tue, Mar 22, 2022 at 1:05 PM Gilles Sadowski  wrote:
>
> Le mar. 22 mars 2022 à 14:46, Matt Juntunen
>  a écrit :
> >
> > Hello,
> >
> > Unless there are any other comments on the PR, I'm going to plan on
> > merging it into master within the next couple of days.
> >
>
> Thanks for providing this new functionality.
>
> Do you envision that [Geometry] will also provide ways to manipulate
> data stored in the map (the "V" in e.g. "PointMap")?
>
> Say, for example, that "V" holds a single (floating-point) value.  We
> insert entries
>   map.put(x, 2);
>   map.put(y, 8);
> assuming that "x" and "y" and just barely different, according to the
> chosen "precision context".  Then:
>   z = (x + y) / 2; // Pseudo-code.
>   m = map.get(z);
> Does "m" equal "2" or "8", depending on whether "z" is (however
> slightly) closer to either "x" or "y"?  Or is it "5" (interpolated value)?
>
> This is related to the feature which I mentioned in GEOMETRY-146.
> I get that the low-level data-structure cannot "make up" a value that
> is not actually stored but it seems that the next step would be an API
> that lets the user specify what it means to retrieve data from the map.
>
> Then, there is also
>   map.put(z, 10);
> Currently "10" will replace either the value at "x" or the value at "y".
> But is it the right behaviour in all cases, or should there be a
> "replacement policy" (to apply whenever points are already stored
> within the "precision context" neighbourhood)?
>
> Does this make sense?
>
> Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: Re: [geometry] PointMap and PointSet

[Matt Juntunen]

Hello,

Unless there are any other comments on the PR, I'm going to plan on
merging it into master within the next couple of days.

Regards,
Matt

On Sun, Mar 20, 2022 at 11:39 AM Matt Juntunen
 wrote:
>
> Hi Eric,
>
> > Would Java’s Map.entrySet provide the “getEntry” type method needed?
> > https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#entrySet--
> > Or would this provide all entry’s and still need to find the specific entry 
> > so maybe a forEach variation to filter for a specific entry?
> > https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#forEach-java.util.function.BiConsumer-
>
> This would work but it would require iterating through half of the set
> on average in order to find the correct entry, meaning we would lose
> the performance benefits of the spatial data structure. The
> PointMap.getEntry() method currently in the PR avoids this iteration
> requirement.
>
> Regards,
> Matt
>
> On Sun, Mar 20, 2022 at 9:13 AM Eric Bresie  wrote:
> >
> >
> >
> >
> > On March 14, 2022 at 10:19:14 AM CDT, Matt Juntunen 
> >  wrote:
> >
> > I'm a little bit confused: Isn't it always the case that
> >
> > getEntry(p).getKey()
> > will return the originally inserted (i.e. "canonical") point (i.e. not "p")?
> >
> > Map does not contain a "getEntry" method. If it did, that would indeed
> > be preferable.
> >
> >
> > Would Java’s Map.entrySet provide the “getEntry” type method needed?
> >
> > https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#entrySet--
> >
> > Or would this provide all entry’s and still need to find the specific entry 
> > so maybe a forEach variation to filter for a specific entry?
> > https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#forEach-java.util.function.BiConsumer-
> >
> > Unless I'm missing a standard use-case, the specialized methods
> >
> > "closestFirst" and "farthestFirst" don't seem useful (and wasteful
> > of computing resources: If iterating over the whole set, why would
> > one want to start from some particular point?).
> >
> >
> > Eric Bresie
> > ebre...@gmail.com
> >
> >

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

Re: Re: [geometry] PointMap and PointSet

[Matt Juntunen]

Hi Eric,

> Would Java’s Map.entrySet provide the “getEntry” type method needed?
> https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#entrySet--
> Or would this provide all entry’s and still need to find the specific entry 
> so maybe a forEach variation to filter for a specific entry?
> https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#forEach-java.util.function.BiConsumer-

This would work but it would require iterating through half of the set
on average in order to find the correct entry, meaning we would lose
the performance benefits of the spatial data structure. The
PointMap.getEntry() method currently in the PR avoids this iteration
requirement.

Regards,
Matt

On Sun, Mar 20, 2022 at 9:13 AM Eric Bresie  wrote:
>
>
>
>
> On March 14, 2022 at 10:19:14 AM CDT, Matt Juntunen 
>  wrote:
>
> I'm a little bit confused: Isn't it always the case that
>
> getEntry(p).getKey()
> will return the originally inserted (i.e. "canonical") point (i.e. not "p")?
>
> Map does not contain a "getEntry" method. If it did, that would indeed
> be preferable.
>
>
> Would Java’s Map.entrySet provide the “getEntry” type method needed?
>
> https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#entrySet--
>
> Or would this provide all entry’s and still need to find the specific entry 
> so maybe a forEach variation to filter for a specific entry?
> https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#forEach-java.util.function.BiConsumer-
>
> Unless I'm missing a standard use-case, the specialized methods
>
> "closestFirst" and "farthestFirst" don't seem useful (and wasteful
> of computing resources: If iterating over the whole set, why would
> one want to start from some particular point?).
>
>
> Eric Bresie
> ebre...@gmail.com
>
>

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

Re: [geometry] PointMap and PointSet

[Matt Juntunen]

Hello,

I've updated the PR [1] with the following changes:
- made the Map.Entry instance returned by PointMap.getEntry() support
the setValue() method for all spaces and dimensions
- created an abstract base class to share code between the 1D PointMap
implementations
- fixed a bug in the 1D spherical point map remove() method
- added additional unit tests

Supporting setValue() in the multidimensional cases was trivial since
I simply returned the actual SimpleEntry instance stored in the map
instead of an immutable wrapper instance. For the 1D cases, I made
getEntry() return a wrapper instance that calls Map.replace() on the
underlying TreeMap when the value is changed. This forces another key
look up but I believe that the small overhead is worth it in order to
provide a consistent PointMap API. In any case,  the overall
performance is not affected since calling put() or replace() is the
only method available to modify a TreeMap entry (outside of using the
entrySet).

Let me know what you think.

Regards,
Matt

[1] https://github.com/apache/commons-geometry/pull/194

On Wed, Mar 16, 2022 at 12:30 PM Gilles Sadowski  wrote:
>
> Hi.
>
> Le mer. 16 mars 2022 à 15:42, Matt Juntunen
>  a écrit :
> >
> > Hello,
> >
> > > I suggest to carefully consider whether to return a "SimpleEntry"
> > (and prominently note that any sort of concurrent modification is
> > a caller responsibility).
> >
> > I see what you mean and I think that would be a good idea. However,
> > the sticking point is that the 1D implementations for both Euclidean
> > and spherical space internally use the JDK's TreeMap class to store
> > entries, due to its superior performance when compared to the
> > AbstractBucketPointMap class used for other dimensions. TreeMap
> > returns immutable Map.Entry instances from its entry-access methods
> > (e.g., ceilingEntry, floorEntry),
>
> The apidocs[1] state:
> ---CUT---
> Map.Entry ceilingEntry(K key)
>Returns a key-value mapping associated with the least key greater
> than or equal to the given key, or null if there is no such key.
> ---CUT---
>
> > so there is not a straightforward
> > way for us to implement the behavior you propose for these dimensions.
>
> AFAICT, (im)mutability of the returned entry is not part of the
> JDK-mandated API.
> So, assuming that the behaviour is implementation-dependent,
> it can be chosen to be different for different dimensions on the
> basis of which behaviour is most "natural" for applications.
>
> > The options I see are:
> > 1. Have all returned entries be immutable (the current behavior).
> > 2. Return specialized Map.Entry implementations for the 1D cases that
> > call the "put" method on the underlying map when "setValue" is called.
> >
> > Option #2 seems less than ideal so unless there is another approach
> > that I'm missing, I vote for #1.
>
> I agree that the situation is somewhat unsatisfying.  But, as said, I'd
> favour #1 only if there were an actual security promise.  Otherwise,
> immutability is a false claim.
> Unless I'm mistaken, calling "put" in order to update the "value" is
> necessarily less performant than calling "setValue" (map search in
> the former, no-op in the latter).
>
> Regards,
> Gilles
>
> [1] 
> https://docs.oracle.com/javase/8/docs/api/java/util/TreeMap.html#ceilingEntry-K-
>
> > Regards,
> > Matt
> >
> >
> > On Wed, Mar 16, 2022 at 9:48 AM Gilles Sadowski  
> > wrote:
> > >
> > > Hi.
> > >
> > > Le mer. 16 mars 2022 à 03:17, Matt Juntunen
> > >  a écrit :
> > > >
> > > > Hello,
> > > >
> > > > I've made the following changes to the PR:
> > > > - removed the "resolveKey" method from PointMap
> > > > - renamed PointMap.resolveEntry to PointMap.getEntry and
> > > > PointSet.resolve to PointSet.get
> > > > - added an entry on PointMap/PointSet to the user guide
> > > > - addressed Github comments (thanks, Bruno!)
> > > >
> > > > I ran some performance tests regarding the immutable entry instance
> > > > created in the PointMap.getEntry method and there seems to be no
> > > > impact.
> > > >
> > > > > Furthermore, what is actually meant here by "immutable
> > > > instance" (since the "value" could be mutable without the
> > > > map being aware of the fact)?
> > > >
> > > > It is immutable in that the object reference used as the entry value
> > > > cannot be changed.

Re: [geometry] PointMap and PointSet

[Matt Juntunen]

Hello,

> I suggest to carefully consider whether to return a "SimpleEntry"
(and prominently note that any sort of concurrent modification is
a caller responsibility).

I see what you mean and I think that would be a good idea. However,
the sticking point is that the 1D implementations for both Euclidean
and spherical space internally use the JDK's TreeMap class to store
entries, due to its superior performance when compared to the
AbstractBucketPointMap class used for other dimensions. TreeMap
returns immutable Map.Entry instances from its entry-access methods
(e.g., ceilingEntry, floorEntry), so there is not a straightforward
way for us to implement the behavior you propose for these dimensions.
The options I see are:
1. Have all returned entries be immutable (the current behavior).
2. Return specialized Map.Entry implementations for the 1D cases that
call the "put" method on the underlying map when "setValue" is called.

Option #2 seems less than ideal so unless there is another approach
that I'm missing, I vote for #1.

Regards,
Matt


On Wed, Mar 16, 2022 at 9:48 AM Gilles Sadowski  wrote:
>
> Hi.
>
> Le mer. 16 mars 2022 à 03:17, Matt Juntunen
>  a écrit :
> >
> > Hello,
> >
> > I've made the following changes to the PR:
> > - removed the "resolveKey" method from PointMap
> > - renamed PointMap.resolveEntry to PointMap.getEntry and
> > PointSet.resolve to PointSet.get
> > - added an entry on PointMap/PointSet to the user guide
> > - addressed Github comments (thanks, Bruno!)
> >
> > I ran some performance tests regarding the immutable entry instance
> > created in the PointMap.getEntry method and there seems to be no
> > impact.
> >
> > > Furthermore, what is actually meant here by "immutable
> > instance" (since the "value" could be mutable without the
> > map being aware of the fact)?
> >
> > It is immutable in that the object reference used as the entry value
> > cannot be changed. This reference could point to a mutable object.
> > This is the same behavior as other Map implementations.
>
> I don't see that "reference immutability" is mandated by the
> "Map" interface (see e.g. [1]).
>
> I've noted many times that I generally favour (true) immutability:
> It makes much sense for "small" data-structures (e.g. for future
> potential optimizations[2]).
>
> However, the "cloud of points" data-structure is at the opposite
> of the spectrum from this POV:  It is intended to contain a large
> number of points whose "key" should indeed be (truly) immutable
> but whose value would likely need to be mutable for many actual
> use cases.
> If a "SimpleImmutableEntry" is returned, then in order to modify
> the map's "value" contents, one has to (IIUC)
>  * retrieve the entry,
>  * create a new value,
>  * call "put" (on the map)
> rather than
>  * retrieve the entry
>  * call "setValue" (on the entry).
> So we have a somewhat crippled API that does not bring any
> advantage since reference immutability doesn't provide any
> security to the map's user (any other caller who is being passed
> the same map, is able to change its contents anyways).
>
> I suggest to carefully consider whether to return a "SimpleEntry"
> (and prominently note that any sort of concurrent modification is
> a caller responsibility).
>
> Regards,
> Gilles
>
> [1] 
> https://docs.oracle.com/javase/8/docs/api/java/util/HashMap.html#entrySet--
> [2] https://cr.openjdk.java.net/~briangoetz/valhalla/sov/02-object-model.html
>
> >>> [...]
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [geometry] PointMap and PointSet

[Matt Juntunen]

Hello,

I've made the following changes to the PR:
- removed the "resolveKey" method from PointMap
- renamed PointMap.resolveEntry to PointMap.getEntry and
PointSet.resolve to PointSet.get
- added an entry on PointMap/PointSet to the user guide
- addressed Github comments (thanks, Bruno!)

I ran some performance tests regarding the immutable entry instance
created in the PointMap.getEntry method and there seems to be no
impact.

> Furthermore, what is actually meant here by "immutable
instance" (since the "value" could be mutable without the
map being aware of the fact)?

It is immutable in that the object reference used as the entry value
cannot be changed. This reference could point to a mutable object.
This is the same behavior as other Map implementations.

Regards,
Matt



On Tue, Mar 15, 2022 at 10:51 AM Gilles Sadowski  wrote:
>
> Hi.
>
> Le mar. 15 mars 2022 à 00:47, Matt Juntunen
>  a écrit :
> >
> > Hello,
> >
> > > Do I understand correctly that the "resolveEntry" method which
> > you added behaves as my above "getEntry"?
> >
> > Correct.
> >
> > > If so, the latter can
> > replace both "resolve" methods, for a (c)leaner API.
> >
> > That would work. I would need to add a matching "get" method to
> > PointSet to provide the same functionality there. One consideration
> > here is that the "resolveEntry" method creates and returns an
> > immutable Entry instance with each call. The "resolveKey" method
> > avoids this.
>
> I had missed that subtlety; but it entails the question of what
> this functionality's intended usage is; e.g. would a user often
> need to access the "key" but not the associated "value"?
>
> Furthermore, what is actually meant here by "immutable
> instance" (since the "value" could be mutable without the
> map being aware of the fact)?
>
> > I'm not sure if this will have an impact on performance.
> > I'll try reducing the API as you suggest and include it in the PR if
> > it doesn't make a difference in performance.
> >
> > Do you prefer the "get" verb over "resolve",
>
> Yes (I'm missing what is being resolved; it's just something
> being accessed).
>
> Best,
> Gilles
>
> > e.g. "getEntry" vs "resolveEntry"?
> >
> > Regards,
> > Matt
> >
> > On Mon, Mar 14, 2022 at 2:19 PM Gilles Sadowski  
> > wrote:
> > >
> > > Hello.
> > >
> > > Le lun. 14 mars 2022 à 16:19, Matt Juntunen
> > >  a écrit :
> > > >
> > > > Gilles,
> > > >
> > > > > it would be great to keep the tutorials/userguide in sync.
> > > >
> > > > Sounds good. I'll update the user guide in this PR.
> > > >
> > > > > I'm a little bit confused: Isn't it always the case that
> > > >   getEntry(p).getKey()
> > > > will return the originally inserted (i.e. "canonical") point (i.e. not 
> > > > "p")?
> > > >
> > > > Map does not contain a "getEntry" method. If it did, that would indeed
> > > > be preferable.
> > >
> > > Do I understand correctly that the "resolveEntry" method which
> > > you added behaves as my above "getEntry"?  If so, the latter can
> > > replace both "resolve" methods, for a (c)leaner API.
> > >
> > > > > Unless I'm missing a standard use-case, the specialized methods
> > > > "closestFirst" and "farthestFirst" don't seem useful (and wasteful
> > > > of computing resources: If iterating over the whole set, why would
> > > > one want to start from some particular point?).
> > > >
> > > > Could you post this comment on the JIRA issue and we can continue the
> > > > discussion there?
> > >
> > > Done.
> > >
> > > Regards,
> > > Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [geometry] PointMap and PointSet

[Matt Juntunen]

Gilles,

> it would be great to keep the tutorials/userguide in sync.

Sounds good. I'll update the user guide in this PR.

> I'm a little bit confused: Isn't it always the case that
  getEntry(p).getKey()
will return the originally inserted (i.e. "canonical") point (i.e. not "p")?

Map does not contain a "getEntry" method. If it did, that would indeed
be preferable.

> Unless I'm missing a standard use-case, the specialized methods
"closestFirst" and "farthestFirst" don't seem useful (and wasteful
of computing resources: If iterating over the whole set, why would
one want to start from some particular point?).

Could you post this comment on the JIRA issue and we can continue the
discussion there?

Regards,
Matt

On Sun, Mar 13, 2022 at 11:25 AM Gilles Sadowski  wrote:
>
> Hello Matt.
>
> Le dim. 13 mars 2022 à 15:41, Matt Juntunen
>  a écrit :
> >
> > Hello,
> >
> > > Is there a gentle introduction to how it works and/or the intended
> > use cases?
> >
> > Not specifically. The implementations are used the same way as JDK
> > Maps and Sets so usage should be very familiar. As far as the internal
> > implementation details, I've tried to describe that in the javadocs
> > for the implementing classes.
> >
> > One example use case is construction of meshes from a stream of
> > triangles. This is used internally in
> > o.a.c.geometry.euclidean.threed.mesh.SimpleTriangleMesh. Another use
> > case is finding unique entries in a cloud of points, where many points
> > are close but not exactly equal to each other. This case was actually
> > posted on the user mailing list (I believe) way back when I started
> > implementing this feature.
>
> I know; but as the code base provides more and more functionality
> (thank you!) it would be great to keep the tutorials/userguide in sync.
> A simple "How to..." is often enough (and faster than browsing the
> Javadoc) in order to get at the most common usage.
>
> >
> > > Does it entail issues about some use cases or applications that
> > need this functionality?  Or do they not generally care about that
> > contract?
> > If so, maybe this collection shouldn't implement the standard JDK
> > interfaces (?).
> >
> > No, there shouldn't be any issues. java.util.TreeMap documents that
> > it's behavior is well-defined and consistent even when a Comparator
> > that doesn't match equals is given, such as
> > String.CASE_INSENSITIVE_ORDER. This is the same sort of situation. The
> > map/set is still quite useful even without the strict contract.
> >
> > > Where does the anticipation come from?
> >
> > The approach I used for helping to maintain somewhat balanced trees in
> > Euclidean 2D and 3D and spherical 2D regardless of insertion order is
> > not based on a well-known algorithm or paper since I was unable to
> > find one. The literature on the subject seems to focus on situations
> > where the inserted points are all known beforehand and can be inserted
> > in a particular order. I did not want to enforce this condition on the
> > API. What I ended up with is just an idea I had for tree balancing
> > that seems to work pretty well. As such, I fully expect that there
> > will be a better option discovered later on.
>
> IMHO, the above two Q & A are worth mentioning in the userguide.
> The second especially may attract some user's attention who could
> provide the missing info.  [Of course, it should also appear at the
> relevant places in the Javadoc.]
>
> >
> > > I don't quite follow; which are the corresponding "non-canonical"
> > accessors?
> >
> > My thought here is that there will be situations where a set of points
> > is placed into a map/set and then these points are queried using
> > values determined from some other source, such as through computations
> > of some sort.
>
> Indeed.
>
> > These query points may vary from the originally inserted
> > points by distances allowed by the Precision.DoubleEquivalence. In
> > these cases, it's useful to be able to obtain the exact value of the
> > originally inserted (i.e. "canonical") point. This is the purpose of
> > the "resolve" methods.
>
> I'm a little bit confused: Isn't it always the case that
>   getEntry(p).getKey()
> will return the originally inserted (i.e. "canonical") point (i.e. not "p")?
>
> Anyways, I'd suggest that this be illustrated in the userguide (linked
> to a working application in "commons-geometry-examples").
>
> >
> > > Is there a not

Re: [geometry] PointMap and PointSet

[Matt Juntunen]

Hello,

> Is there a gentle introduction to how it works and/or the intended
use cases?

Not specifically. The implementations are used the same way as JDK
Maps and Sets so usage should be very familiar. As far as the internal
implementation details, I've tried to describe that in the javadocs
for the implementing classes.

One example use case is construction of meshes from a stream of
triangles. This is used internally in
o.a.c.geometry.euclidean.threed.mesh.SimpleTriangleMesh. Another use
case is finding unique entries in a cloud of points, where many points
are close but not exactly equal to each other. This case was actually
posted on the user mailing list (I believe) way back when I started
implementing this feature.

> Does it entail issues about some use cases or applications that
need this functionality?  Or do they not generally care about that
contract?
If so, maybe this collection shouldn't implement the standard JDK
interfaces (?).

No, there shouldn't be any issues. java.util.TreeMap documents that
it's behavior is well-defined and consistent even when a Comparator
that doesn't match equals is given, such as
String.CASE_INSENSITIVE_ORDER. This is the same sort of situation. The
map/set is still quite useful even without the strict contract.

> Where does the anticipation come from?

The approach I used for helping to maintain somewhat balanced trees in
Euclidean 2D and 3D and spherical 2D regardless of insertion order is
not based on a well-known algorithm or paper since I was unable to
find one. The literature on the subject seems to focus on situations
where the inserted points are all known beforehand and can be inserted
in a particular order. I did not want to enforce this condition on the
API. What I ended up with is just an idea I had for tree balancing
that seems to work pretty well. As such, I fully expect that there
will be a better option discovered later on.

> I don't quite follow; which are the corresponding "non-canonical"
accessors?

My thought here is that there will be situations where a set of points
is placed into a map/set and then these points are queried using
values determined from some other source, such as through computations
of some sort. These query points may vary from the originally inserted
points by distances allowed by the Precision.DoubleEquivalence. In
these cases, it's useful to be able to obtain the exact value of the
originally inserted (i.e. "canonical") point. This is the purpose of
the "resolve" methods.

> Is there a notion of neighbours (as in: return the "n" entries that
are closest to a given point)?

I am picturing that functionality being implemented in a follow-up issue. [1]

Regards,
Matt

[1] https://issues.apache.org/jira/browse/GEOMETRY-146

On Sat, Mar 12, 2022 at 10:36 AM Gilles Sadowski  wrote:
>
> Hello.
>
> Le ven. 11 mars 2022 à 16:18, Matt Juntunen
>  a écrit :
> >
> > Hello,
> >
> > I recently posted a PR [1] for GEOMETRY-142 [2], which is for adding
> > PointMap and PointSet implementations. These are Map and Set
> > implementations specifically designed to use Points as keys.
>
> Is there a gentle introduction to how it works and/or the intended
> use cases?
>
> > They
> > support fuzzy key comparison, meaning that points do not have to be
> > exactly equal to each other in order to be considered equal by the
> > map/set. (Note that this means these types do not follow the strict
> > Map/Set contracts since they are not consistent with equals. This is
> > documented in the PointMap/PointSet javadocs.)
>
> Does it entail issues about some use cases or applications that
> need this functionality?  Or do they not generally care about that
> contract?
> If so, maybe this collection shouldn't implement the standard JDK
> interfaces (?).
>
> > I've completely hidden
> > the implementation details from the public API
>
> Thanks.
>
> > since I anticipate
> > changes in the future with regard to the algorithms used.
>
> Where does the anticipation come from?
>
> > Instances
> > are created through factory classes in each space. Ex:
> >
> > PointMap map = EuclideanCollections.pointMap3D(precision);
> > PointSet set = SphericalCollections.pointSet2S(precision);
> >
> > Since fuzzy key comparison is used, I've added the following methods
> > to the interfaces to allow access to the exact, "canonical" version of
> > the key stored in the collection.
> >
> > PointMap  {
> > // return the key corresponding to pt, or null if not found
> > P resolveKey(P pt);
> >
> > // return the map entry corresponding to pt, or null if not found
> > Map.Entry resolveEntry(P pt);
> > }
> >
> > PointSet {
&

[geometry] 1.1 Roadmap

[Matt Juntunen]

Hello,

As mentioned in my previous email, I have recently created a PR for
GEOMETRY-142 (PointMap/Set implementations), which is one of the major
features I wanted for the next release of commons-geometry. Other than
that, here is what I'm picturing for inclusion in this next version:
- GEOMETRY-142 - Implement a 3D convex hull algorithm.
- GEOMETRY-144 - Clean up the convex hull API and get that module
ready for release.
- ??? - Perhaps add a method to PointMap/Set (from GEOMETRY-142) to
locate the closest point in the collection to a given point.

Any thoughts on this? Is there anything else that we should plan on for 1.1?

Regards,
Matt Juntunen

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

[geometry] PointMap and PointSet

[Matt Juntunen]

Hello,

I recently posted a PR [1] for GEOMETRY-142 [2], which is for adding
PointMap and PointSet implementations. These are Map and Set
implementations specifically designed to use Points as keys. They
support fuzzy key comparison, meaning that points do not have to be
exactly equal to each other in order to be considered equal by the
map/set. (Note that this means these types do not follow the strict
Map/Set contracts since they are not consistent with equals. This is
documented in the PointMap/PointSet javadocs.) I've completely hidden
the implementation details from the public API since I anticipate
changes in the future with regard to the algorithms used. Instances
are created through factory classes in each space. Ex:

PointMap map = EuclideanCollections.pointMap3D(precision);
PointSet set = SphericalCollections.pointSet2S(precision);

Since fuzzy key comparison is used, I've added the following methods
to the interfaces to allow access to the exact, "canonical" version of
the key stored in the collection.

PointMap  {
// return the key corresponding to pt, or null if not found
P resolveKey(P pt);

// return the map entry corresponding to pt, or null if not found
Map.Entry resolveEntry(P pt);
}

PointSet {
// return the key corresponding to pt, or null if not found
P resolve(P pt);
}

Reviews and comments are welcome.

Regards,
Matt Juntunen


[1] https://github.com/apache/commons-geometry/pull/194
[2] https://issues.apache.org/jira/projects/GEOMETRY/issues/GEOMETRY-142

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

Re: [All] GSoC 2022

[Matt Juntunen]

I just added a similar placeholder issue for geometry:
https://issues.apache.org/jira/browse/GEOMETRY-145. I hope those are
the kinds of ideas we're going for here.

Regards,
Matt J

On Wed, Feb 23, 2022 at 12:05 PM Gilles Sadowski  wrote:
>
> Ping.
>
> Nothing for "Geometry", "Statistics", ... (?)
> ;-)
>
> Regards,
> Gilles
>
> Le mer. 9 févr. 2022 à 14:57, Gilles Sadowski  a écrit :
> >
> > Hi.
> >
> > >>> [...]
> > > > >
> > > > > Shall we open a "GSoC 2022" report in each concerned JIRA project?
> > > >
> > > > Yes. I think we just create some tickets and tag them with the
> > > > appropriate tag (GSOC 2022 ?). There should be some left over from
> > > > last time to repurpose or use as templates for new ones.
> > >
> > > Actually, I was thinking of creating one global "GSoC 2022" issue
> > > in each component, that would list all the topics and a complete
> > > description of their respective goal,
> >
> > Done for "Commons Math":
> >https://issues.apache.org/jira/browse/MATH-1641
> >
> > Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [Geometry] Issues (?) with the "hull" module[1]

[Matt Juntunen]

Hello.

> OK.  Did I understand correctly that the functionality is already
> there, with several implementations)?

We only have one convex hull implementation (MonotoneChain) and that
one is only for 2D. Before we release, I'd like to at least have
implementations for Euclidean 2D and 3D. I'm thinking we should design
the API so that we only present a single convex hull operation per
dimension and keep the actual implementation private, so we can
replace the algorithm if/when better alternatives become available.

Regards,
Matt

On Mon, Jan 17, 2022 at 9:10 AM Gilles Sadowski  wrote:
>
> Hello.
>
> Le lun. 17 janv. 2022 à 14:16, Matt Juntunen
>  a écrit :
> >
> > Hi Gilles,
> >
> > The main things I want to do on the hull module are
> > - Review the public API to see if any changes need to be made. (ex:
> > make AklToussaintHeuristic internal)
>
> Good suggestion; I'll minimize the public API.[1]
>
> > - Add QuickHull implementations for 2D/3D (GEOMETRY-110). This is
> > currently blocked due to the need for a PointMap implementation, which
> > I am working on now in GEOMETRY-142.
>
> OK.  Did I understand correctly that the functionality is already
> there, with several implementations)?  If so, we could in effect
> make all those private, and select a different alternative whenever
> a more performant algorithm is available.
>
> Best,
> Gilles
>
> [1] I've created https://issues.apache.org/jira/browse/GEOMETRY-144
>
> > On Sun, Jan 16, 2022 at 12:59 PM Gilles Sadowski  
> > wrote:
> > >
> > > Hello.
> > >
> > > Could you remind me what work needs to be done so that this
> > > functionality can make it into the next release of [Geometry]?
> > >
> > > Thanks,
> > > Gilles
> > >
> > > [1] 
> > > https://gitbox.apache.org/repos/asf?p=commons-geometry.git;a=tree;f=commons-geometry-hull;h=a3dd796c9c418e10768cda5998f89c19e7439f28;hb=HEAD
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [Geometry] Issues (?) with the "hull" module[1]

[Matt Juntunen]

Hi Gilles,

The main things I want to do on the hull module are
- Review the public API to see if any changes need to be made. (ex:
make AklToussaintHeuristic internal)
- Add QuickHull implementations for 2D/3D (GEOMETRY-110). This is
currently blocked due to the need for a PointMap implementation, which
I am working on now in GEOMETRY-142.

Regards,
Matt J

On Sun, Jan 16, 2022 at 12:59 PM Gilles Sadowski  wrote:
>
> Hello.
>
> Could you remind me what work needs to be done so that this
> functionality can make it into the next release of [Geometry]?
>
> Thanks,
> Gilles
>
> [1] 
> https://gitbox.apache.org/repos/asf?p=commons-geometry.git;a=tree;f=commons-geometry-hull;h=a3dd796c9c418e10768cda5998f89c19e7439f28;hb=HEAD
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [statistics] Release 1.0

[Matt Juntunen]

If the functionality is mature, I would vote for a 1.0 release. YOLO :-)
-Matt J

On Tue, Sep 14, 2021 at 11:13 AM Alex Herbert  wrote:
>
> The statistics component is a candidate for a release.
>
> The statistics distributions module contains mature functionality
> ported from CM. The dependency on [numbers] is now satisfied as that
> has had an official release. There is nothing outstanding in the
> project Jira. Thus a first release of this component can be performed.
>
> Items before a release:
>
> - Remaining Jira tickets should be checked and resolved
> - Should a release go out as an alpha, beta or simply a 1.0?
>
> Alex
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [VOTE][RC3] Release Commons RNG 1.4

[Matt Juntunen]

Builds with JDK 8 and 11 from source distribution and tag.
Checksums and signatures are good.
Tag is good.

[X] +1 Release these artifacts

Regards,
Matt J

On Thu, Sep 9, 2021 at 6:45 AM Gilles Sadowski  wrote:
>
> Le mer. 8 sept. 2021 à 12:01, Alex Herbert  a écrit 
> :
> >
> > We have fixed quite a few bugs and added some significant enhancements
> > since Apache Commons RNG 1.3 was released, so I would like to release
> > Apache Commons RNG 1.4.
> >
> > Apache Commons RNG 1.4 RC3 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/rng/1.4-RC3 (svn
> > revision 49824)
> > https://home.apache.org/~aherbert/commons-rng-1.4-RC3-site/
> >
> > The Git tag commit for this RC is RNG_1_4_RC3 which you can browse here:
> >
> > https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=commit;h=RNG_1_4_RC3
> >
> > You may checkout this tag using:
> > git clone https://gitbox.apache.org/repos/asf/commons-rng.git --branch
> > RNG_1_4_RC3 commons-rng-1.4-RC3
> > (signature can be checked from git using 'git tag -v RNG_1_4_RC3')
> >
> > [...]
>
> Tag checked.
> Successfully built with Java 8 (on Debian GNU/Linux) and
> with Java 11 (using the "examples" profile).
> Archive files' checksums are OK.
>
> [X] +1 Release these artifacts
>
> >   [ ] +0 OK, but...
> >   [ ] -0 OK, but really should fix...
> >   [ ] -1 I oppose this release because...
> >
> > [...]
>
> Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [VOTE][RC2] Release Commons RNG 1.4

[Matt Juntunen]

Got it. In that case...

- Reports look good.
- Hashes and signatures are good.
- Userguide now lists JDK 8 as a requirement.
- Builds with the following (from the source distribution):

mvn clean install site site:stage -Pcommons-rng-examples

Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: C:\Users\matt\tools\apache-maven-3.6.3-bin\apache-maven-3.6.3\bin\..
Java version: 11.0.12, vendor: Eclipse Foundation, runtime: C:\Program
Files\Eclipse Foundation\jdk-11.0.12.7-hotspot
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

mvn clean install

Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
2018-02-24T14:49:05-05:00)
Maven home: /home/matt/tools/maven/apache-maven-3.5.3
Java version: 1.8.0_292, vendor: Private Build
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.4.0-81-generic", arch: "amd64", family: "unix"

Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
2018-02-24T14:49:05-05:00)
Maven home: /home/matt/tools/maven/apache-maven-3.5.3
Java version: 11.0.2, vendor: Oracle Corporation
Java home: /home/matt/lang/java/jdk-11.0.2
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.4.0-81-generic", arch: "amd64", family: "unix"

[X] +1 Release these artifacts

Regards,
Matt Juntunen


On Mon, Sep 6, 2021 at 8:53 AM Alex Herbert  wrote:
>
> Hi,
>
> On Mon, 6 Sept 2021 at 13:13, Matt Juntunen 
> wrote:
>
> > The windows build is fixed. Before I cast my vote, can someone remind
> > me what to do to verify the nexus artifacts?
> >
>
> Thanks for checking.
>
> The nexus items are convenience artifacts. IIUC the vote is specifically
> for the source release. All derived release artifacts are non-essential to
> the release vote.
>
> The link in the vote e-mail for the nexus artifacts was wrong (I did not
> change it from the auto generated link created by the commons release
> plugin). Here are the artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1571/org/apache/commons/
>
> A laborious way to verify them is to download them, manually install them
> or put them on the classpath and then run them in a test application. You
> can add this repository to a maven project POM and then maven should be
> able to download them (I've not tried that but may give it a go to check if
> it's possible). An ideal way to test them would be to run all the unit
> tests from the source download against the maven artifacts. I do not recall
> anyone performing these actions on a previous vote. A quick browse of the
> staged artifacts to check the expected jars are present should be enough.
> The release guide expects for each module:
>
> .pom
> .jar
> .javadoc.jar
> .sources.jar
> .tests.jar
> .test-sources.jar
>
> The parent POM should also be staged.
>
> I did notice that the parent module has a site.xml staged in nexus. This
> must be a default for any project with the pom packaging as it also happens
> for commons-parent (you can find this in maven central). I do not know why
> you would want to include the site.xml as a dependency so perhaps this is
> something to clean up in the commons release plugin.
>
> Alex

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

Re: [VOTE][RC2] Release Commons RNG 1.4

[Matt Juntunen]

The windows build is fixed. Before I cast my vote, can someone remind
me what to do to verify the nexus artifacts?

Regards,
Matt J

On Mon, Sep 6, 2021 at 6:09 AM Alex Herbert  wrote:
>
> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons RNG 1.3 was released, so I would like to release
> Apache Commons RNG 1.4.
>
> Apache Commons RNG 1.4 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/rng/1.4-RC2 (svn
> revision 49779)
> https://home.apache.org/~aherbert/commons-rng-1.4-RC2-site/
>
> The Git tag commit for this RC is RNG_1_4_RC1 which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=commit;h=RNG_1_4_RC
> 
> 2
>
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-rng.git --branch
> RNG_1_4_RC2 commons-rng-1.4-RC2
> (signature can be checked from git using 'git tag -v RNG_1_4_RC2')
>
> Commit ID the tag points at:
> 4d55aebc1e0ac6cab0f451ef5f3f54cd6e5440a6
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1571/org/apache/commons/commons-rng/1.4/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Mon Sep 06 10:41:09 BST 2021
> commons-rng-1.4-bin.tar.gz=0d3a2b7f35e31f14cd9e204fb69ba973782d5955cf106bf4972831fb19a8e99001a0baef952283103f82be255c33fc218285dea53357dc725c6fa1d5059855db
> commons-rng-1.4-bin.zip=2493405ad742a4b26d7c1e7adbfeae2809a2e27f1301c468c9a2fe43e1ebda94393da4d6cbcafb858d95be2bb7b5ef07d105873f2780c336c78c5c9fb0fd8694
> commons-rng-1.4-src.tar.gz=5ac9d49c6fc493bf619ce6b0b35cd537528c95094f711debadbce195c87aefbeb19a886ca3bb507954bc1ab8cc20ea5c84cf65e38c67e800d473960def198a9a
> commons-rng-1.4-src.zip=8403d574021b4f66bc2cdeb3226a246e5ae9f9b5852bba488ce244f306f7b4f0bb43d7be38993b965c9811c790e2ee5d3d3e77e93474532fee2073a207fc7143
>
> The source code contains examples that are not part of the public API.
> These examples contain Java 11 modules and are enabled using a profile (see
> below).
>
> Note: Testing randomness using statistical thresholds results in failures
> at a given probability. The 'maven-surefire-plugin' is configured to re-run
> tests that fail, and pass the build if they succeed within the allotted
> number of reruns (the test will be marked as 'flaky' in the report).
>
> I have tested this with 'mvn clean install' using:
>
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /usr/local/apache-maven-3.6.3
> Java version: 1.8.0_241, vendor: Oracle Corporation, runtime:
> /usr/lib/jvm/jdk1.8.0_241/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.15.0-153-generic", arch: "amd64", family:
> "unix"
>
> I have tested this with 'mvn clean package site site:stage
> -Pcommons-rng-examples' using:
>
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /usr/local/apache-maven-3.6.3
> Java version: 11.0.11, vendor: Ubuntu, runtime:
> /usr/lib/jvm/java-11-openjdk-amd64
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.15.0-153-generic", arch: "amd64", family:
> "unix"
>
> I tested the RC1 issues with the site build have been resolved:
>
> mvn pre-site (does nothing)
> mvn site site:stage -DgenerateReports=false
> open target/staging/userguide/rng.html#a7._Dependencies
>
> The userguide dependencies section lists Java 1.8+.
>
> Details of changes since 1.3 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/rng/1.4-RC2/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/rng/1.4-RC2/site/changes-report.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/rng/1.4-RC2/site/index.html
> (note some *relative* links are broken and the 1.4 directories are not
> yet created - these will be OK once the site is deployed.)
>
> JApiCmp Report (compared to 1.3):
>
> https://home.apache.org/~aherbert/commons-rng-1.4-RC2-site/commons-rng-client-api/japicmp.html
>
> https://home.apache.org/~aherbert/commons-rng-1.4-RC2-site/commons-rng-core/japicmp.html
>
> https://home.apache.org/~aherbert/commons-rng-1.4-RC2-site/commons-rng-simple/japicmp.html
>
> https://home.apache.org/~aherbert/commons-rng-1.4-RC2-site/commons-rng-sampling/japicmp.html
>
>
> RAT Report:
>
> https://home.apache.org/~aherbert/commons-rng-1.4-RC2-site/rat-report.html
>
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner than 72 hours from now.
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
> Thank you,
>
> Alex Herbert,
> Release Manager (using key BC87A3FD0A54480F0BADBEBD21939FF0CA2A6567)
>
> The following is intended as a helper and refresher for reviewers.
>
> Validating 

Re: [VOTE][RC1] Release Commons RNG 1.4

[Matt Juntunen]

Hi Alex,

> The .gitignore file contains the entry 'site-content*'. This allows the
> file to be ignored in Linux or Mac. I've never tried windows.  So this fails?

> mvn pre-site
> mvn apache-rat:check

Yes, it fails. I'm building from the source distribution which does
not include the .gitignore file. It will pass if I either
- add a .gitignore file with a "site-content*" entry or
- add "**/site-content.README" as an exclusion in the pom rat configurations.

The second option is what I did for commons-geometry.

-Matt

On Sun, Sep 5, 2021 at 9:38 AM Alex Herbert  wrote:
>
> Hi,
>
> On Sun, 5 Sept 2021 at 13:51, Matt Juntunen 
> wrote:
>
>
> > [ERROR] Failed to execute goal
> > org.apache.rat:apache-rat-plugin:0.13:check (rat-check) on project
> > commons-rng-parent: Too many files with unapproved license: 1 See RAT
> > report in:
> > C:\Users\matt\projects\commons-rng-1.4-src\commons-rng-1.4-src\target\rat.txt
> > -> [Help 1]
> >
> > The failed file is site-content.README. In commons-geometry, I had to
> > explicitly add this file to the rat excludes in the pom in order to
> > get the build to pass.
> >
>
> The .gitignore file contains the entry 'site-content*'. This allows the
> file to be ignored in Linux or Mac. I've never tried windows. So this fails?
>
> mvn pre-site
> mvn apache-rat:check
>
> Because the newly created site-content.README is not ignored on windows.
>
>
> > I also noticed that the userguide Dependencies section still lists the
> > required Java version as 1.7+. I don't consider that a blocker in
> > itself but we might want to update that as well.
> >
>
> Thanks for spotting the issue.
>
> Given the issues with the site-content download I think I will fix this and
> re-roll an RC2.
>
> Alex

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

Re: [VOTE][RC1] Release Commons RNG 1.4

[Matt Juntunen]

I ran into an error building from the source distribution on Windows.

C:\Users\matt\projects\commons-rng-1.4-src\commons-rng-1.4-src> mvn -v
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: C:\Users\matt\tools\apache-maven-3.6.3-bin\apache-maven-3.6.3\bin\..
Java version: 11.0.12, vendor: Eclipse Foundation, runtime: C:\Program
Files\Eclipse Foundation\jdk-11.0.12.7-hotspot
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

C:\Users\matt\projects\commons-rng-1.4-src\commons-rng-1.4-src>mvn
clean package site site:stage -Pcommons-rng-examples
...
[INFO] Reactor Summary for Apache Commons RNG 1.4:
[INFO]
[INFO] Apache Commons RNG . FAILURE [  4.472 s]
[INFO] Apache Commons RNG Client API .. SKIPPED
[INFO] Apache Commons RNG Core  SKIPPED
[INFO] Apache Commons RNG Simple .. SKIPPED
[INFO] Apache Commons RNG Sampling  SKIPPED
[INFO] Apache Commons RNG Examples  SKIPPED
[INFO] Apache Commons RNG Examples Stress Utilities ... SKIPPED
[INFO] Apache Commons RNG Examples Sampling Utilities . SKIPPED
[INFO] Apache Commons RNG Quadrature Example .. SKIPPED
[INFO] Apache Commons RNG JMH Benchmark ... SKIPPED
[INFO] Apache Commons RNG JPMS Integration Test ... SKIPPED
[INFO] Apache Commons RNG JPMS Module Example (Library) ... SKIPPED
[INFO] Apache Commons RNG JPMS Module Example (Application) SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time:  5.207 s
[INFO] Finished at: 2021-09-05T08:43:29-04:00
[INFO] 
[ERROR] Failed to execute goal
org.apache.rat:apache-rat-plugin:0.13:check (rat-check) on project
commons-rng-parent: Too many files with unapproved license: 1 See RAT
report in: 
C:\Users\matt\projects\commons-rng-1.4-src\commons-rng-1.4-src\target\rat.txt
-> [Help 1]

The failed file is site-content.README. In commons-geometry, I had to
explicitly add this file to the rat excludes in the pom in order to
get the build to pass.

I also noticed that the userguide Dependencies section still lists the
required Java version as 1.7+. I don't consider that a blocker in
itself but we might want to update that as well.

Everything else looks good.

Regards,
Matt J


On Sat, Sep 4, 2021 at 12:58 PM Alex Herbert  wrote:
>
> Note it also prevents a site build if you don't have SVN installed.
>
> My previous changes to this were to continue its support but improve it to
> a minimal download. I'll move this functionality to a profile as it is only
> of concern when updating the site.
>
> Alex
>
> On Sat, 4 Sep 2021, 14:46 Gilles Sadowski,  wrote:
>
> > Hello.
> >
> > Le ven. 3 sept. 2021 à 09:32, Alex Herbert  a
> > écrit :
> > >
> > > Hi,
> > >
> > > On Fri, 3 Sept 2021 at 00:29, Gilles Sadowski 
> > wrote:
> > >
> > >
> > > >
> > > > I noticed that missing "site-content" directories still lead to the
> > > > contents being downloaded as part of the build.
> > > > I thought the "fix" was that it would not occur by default; or did
> > > > I miss something?
> > > >
> > >
> > > The current solution is that the top-level directory of the existing site
> > > is checked out in the parent module (i.e. non recursive site checkout).
> > So
> > > you do get a few files logged by maven as being checked out during the
> > > 'site' goal. There should be a 'site-content.README' file created which
> > > contains information about the site-content directory. It has to be
> > outside
> > > the site-content directory. In all the child modules an otherwise empty
> > > site-content directory is created with a README inside to indicate why it
> > > is there. A repeat of the site build should detect all the directories
> > are
> > > present and not invoke the checkout again.
> > >
> > > All this should be removed by using the 'clean' goal.
> > >
> > > Are you getting a total site checkout or just the solution I described?
> >
> > It works as you describe.
> >
> > Taking a step back, I'm still missing why there is any download
> > from SVN in order to fulfill the "site" target (a local build of the site
> > from the source release should not need "external" material, IIUC).
> >
> > Regards,
> > Gilles
> >
> > > [...]
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >

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

Re: Top Contributor in the Commons PMC

[Matt Juntunen]

I second this congratulations. Thank you for all of your hard work!

-Matt J

On Fri, Sep 3, 2021 at 8:46 AM Gary Gregory  wrote:
>
> If only quantity was equivalent to quality ;-)
>
> Thanks Bernd :-)
>
> Gary
>
>
> On Tue, Aug 31, 2021, 11:44 Bernd Eckenfels  wrote:
>
> > Congrats Gary to be recognized as a top committer and top (mail) sender in
> > the recent ASF Report ,)
> >
> > https://s.apache.org/FY2021AnnualReport
> >
> > Gruss
> > Bernd
> >

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

[ANNOUNCEMENT] Apache Commons Geometry Version 1.0 Released

[Matt Juntunen]

The Apache Commons Team is pleased to announce the availability of
version 1.0 of "Apache Commons Geometry".

The Apache Commons Geometry project provides geometric types and utilities.

Changes in this version include:

New features:
o GEOMETRY-118:  Add coordinate-specific transform methods to
AffineTransformMatrixXD classes, e.g. "applyX", "applyY", "applyZ".
o GEOMETRY-95:  Add solid geometry tutorial.
o GEOMETRY-120:  Add SimpleTriangleMeshBuilder.addFace(int[]) method as
alternative to addFace(int, int, int).
o GEOMETRY-117:  Add shear methods to AffineTransformMatrix2D. Thanks to
Christoph Läubrich.
o GEOMETRY-119:  Add VectorXD.normalizeOrNull() methods so that callers can
detect normalization failures without needing to catch an exception.
o GEOMETRY-115:  Add modules for IO functionality: commons-geometry-io-core,
commons-geometry-io-euclidean.
o GEOMETRY-108:  Add BoundaryList interface and implementation classes.

Fixed Bugs:
o GEOMETRY-116:  Fix incorrect OSGi headers. Reported by Christoph Läubrich.

Changes:
o GEOMETRY-138:  Do not use checked exceptions in IO modules.
o GEOMETRY-13:  Use Norms.EUCLIDEAN from Commons Numbers to compute 3D
Euclidean norm values.
o GEOMETRY-126:  Replace VectorXD.linearCombination methods with VectorXD.Sum
classes. Use Sum class from Commons Numbers for computing internal
linear combinations.
o GEOMETRY-124:  Replace DoublePrecisionContext with
Precision.DoubleEquivalence from Commons Numbers.
o GEOMETRY-109:  Rename the BoundarySourceXX.from() static factory methods to
"of" to better match the JDK's Stream.of() method.
o GEOMETRY-103:  Migrate unit tests to JUnit 5. Thanks to Arturo Bernal.


Historical list of changes:
  https://commons.apache.org/proper/commons-geometry/changes-report.html

For complete information on Apache Commons Geometry, including instructions
on how to submit bug reports, patches, or suggestions for improvement, see the
Apache Commons Geometry website:
  https://commons.apache.org/proper/commons-geometry/

Distribution packages can be downloaded from
  http://commons.apache.org/proper/commons-geometry/download_geometry.cgi


Matt Juntunen,
Apache Commons Team

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

Re: [RESULT][VOTE] Release Apache Commons Geometry 1.0 based on RC4

[Matt Juntunen]

This vote passes with the following +1s.
- Alex Herbert (binding)
- Gilles Sadowski (binding)
- Matt Juntunen (binding)

I will work on getting the release out later tonight.

Regards,
Matt J

On Tue, Aug 17, 2021 at 3:22 AM Matt Juntunen  wrote:
>
> We have completed initial development work on Apache Commons Geometry,
> so I would like to release Apache Commons Geometry (full distribution)
> 1.0.
>
> Apache Commons Geometry (full distribution) 1.0 RC4 is available for
> review here:
> https://dist.apache.org/repos/dist/dev/commons/geometry/1.0-RC4
> (svn revision 49526)
>
> The Git tag commons-geometry-1.0-rc4 commit for this RC is
> 5326851864f93a486409562628afaaa485b6d99f which you can browse here:
> 
> https://gitbox.apache.org/repos/asf?p=commons-geometry.git;a=commit;h=5326851864f93a486409562628afaaa485b6d99f
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-geometry.git
> --branch commons-geometry-1.0-rc4 commons-geometry-1.0-rc4
>
> Maven artifacts are here:
> https://repository.apache.org/content/repositories/orgapachecommons-1566/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Mon Aug 16 21:52:18 EDT 2021
> commons-geometry-1.0-bin.tar.gz=b170b25f0c4c7837a51c8c3b37aa970c755c5610b16e6afa82f4cfea6dfa14f347366932e4e0ded921150ad4ad349f1d16661934925da6ece7253599fbd90cf0
> commons-geometry-1.0-bin.zip=3a1c4de02f684d9837ee3284b3a35bac2369d3ea9994354218bcc0d3480330c174054b536dc02104b55a3dadee91c56a66742dd830f19dbdee5f765faf1ec596
> commons-geometry-1.0-src.tar.gz=ad2c89958a3a6278135b2c820bc5c6d97edc49ea8dd119c44c49e764248e068ff0404b04cb620d0f10a7172b69ee0907f39483119c1fcd695ffe58f4c0d3731a
> commons-geometry-1.0-src.zip=45c467545a84347b89319077c5c1221a5e908894a32f61f713909b2905d006de89cf4a73dc99b29b31c01c2fa28a73f71bd4ff4d530f2264a06c6a118a02b8ad
>
> (no need for .asc hashes!)
>
> I have tested this with ***'mvn clean install site'*** using:
> ***
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
> 2018-02-24T14:49:05-05:00)
> Maven home: /home/matt/tools/maven/apache-maven-3.5.3
> Java version: 1.8.0_292, vendor: Private Build
> Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.4.0-80-generic", arch: "amd64", family: "unix"
>
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
> 2018-02-24T14:49:05-05:00)
> Maven home: /home/matt/tools/maven/apache-maven-3.5.3
> Java version: 11.0.2, vendor: Oracle Corporation
> Java home: /home/matt/lang/java/jdk-11.0.2
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.4.0-80-generic", arch: "amd64", family: "unix"
>
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
> 2018-02-24T14:49:05-05:00)
> Maven home: /home/matt/tools/maven/apache-maven-3.5.3
> Java version: 16.0.1, vendor: AdoptOpenJDK
> Java home: /home/matt/lang/java/jdk-16.0.1+9
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.4.0-80-generic", arch: "amd64", family: "unix"
>
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: 
> C:\Users\matt\tools\apache-maven-3.6.3-bin\apache-maven-3.6.3\bin\..
> Java version: 1.8.0_242, vendor: AdoptOpenJDK, runtime: C:\Program
> Files\AdoptOpenJDK\jdk-8.0.242.08-hotspot\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> ***
>
> Details of changes since 1.0-beta1 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/geometry/1.0-RC4/RELEASE-NOTES.txt
>
> Site:
> https://home.apache.org/~mattjuntunen/commons-geometry-1.0-RC4-site/
> (note some *relative* links are broken and the 1.0 directories are
> not yet created - these will be OK once the site is deployed.)
>
> CLIRR Report:
> N/A
>
> JApiCmp Report:
> N/A
>
> RAT Report:
> 
> https://home.apache.org/~mattjuntunen/commons-geometry-1.0-RC4-site/rat-report.html
>
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner than 72 hours from now.
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 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.
>
>

Re: [VOTE] Release Apache Commons Geometry (full distribution) 1.0 based on RC4

[Matt Juntunen]

For the record, here is my +1 vote.
-Matt

On Fri, Aug 20, 2021 at 4:18 PM Matt Juntunen  wrote:
>
> This is good to know. Thanks for looking into this, Alex!
> -Matt
>
> On Thu, Aug 19, 2021 at 1:45 PM Alex Herbert  wrote:
> >
> > It is definitely platform dependent. JDK 11.0.12 on my MacOS did not show
> > warnings. JDK 11.0.11 on my linux workstation did show warnings in the
> > euclidean module.
> >
> > Java. Build once, run anywhere, but with variations.
> >
> > These are not warnings about private @value tags. These are
> > incorrect @inheritDoc:
> >
> > 6 warnings
> > [WARNING] Javadoc Warnings
> > [WARNING]
> > /tmp/commons-geometry-1.0-rc4/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/twod/ReverseRay.java:181:
> > warning - @inheritDoc used but splitOnIntersection(Line, Vector2D) does not
> > override or implement any method.
> > [WARNING]
> > /tmp/commons-geometry-1.0-rc4/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/twod/ReverseRay.java:181:
> > warning - @inheritDoc used but splitOnIntersection(Line, Vector2D) does not
> > override or implement any method.
> > [WARNING]
> > /tmp/commons-geometry-1.0-rc4/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/twod/ReverseRay.java:181:
> > warning - @inheritDoc used but splitOnIntersection(Line, Vector2D) does not
> > override or implement any method.
> > [WARNING]
> > /tmp/commons-geometry-1.0-rc4/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/twod/ReverseRay.java:181:
> > warning - @inheritDoc used but splitOnIntersection(Line, Vector2D) does not
> > override or implement any method.
> > [WARNING]
> > /tmp/commons-geometry-1.0-rc4/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/twod/ReverseRay.java:181:
> > warning - @inheritDoc used but splitOnIntersection(Line, Vector2D) does not
> > override or implement any method.
> > [WARNING]
> > /tmp/commons-geometry-1.0-rc4/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/twod/ReverseRay.java:181:
> > warning - @inheritDoc used but splitOnIntersection(Line, Vector2D) does not
> > override or implement any method.
> >
> > I do not see warnings in other modules.
> >
> > These are the same warnings that Gilles reported. But on closer inspection
> > it is the same warning 6 times. The line in question in ReverseRay does
> > correctly override a method. So this is a bug in the javadoc tool on the
> > linux platform. This explains why I did not see it on another build env.
> > Because it is not a javadoc issue but an issue with the javadoc tool.
> >
> > If I run this with JDK 8 (1.8.0_241) on the same linux machine then I do
> > not see the warnings in this or any other module.
> >
> > Alex
> >
> >
> > On Thu, 19 Aug 2021 at 15:34, Matt Juntunen 
> > wrote:
> >
> > > The warnings about the unknown references seem to be caused by using
> > > the @value tag to reference the value of a private constant. In my
> > > experience, they only appear on JDK 8 and not 11+. I consider this
> > > usage worth the warning since it ensures that the value given in the
> > > docs actually matches what's in the code.
> > >
> > > Regards,
> > > Matt J
> > >

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

Re: [VOTE] Release Apache Commons Geometry (full distribution) 1.0 based on RC4

[Matt Juntunen]

This is good to know. Thanks for looking into this, Alex!
-Matt

On Thu, Aug 19, 2021 at 1:45 PM Alex Herbert  wrote:
>
> It is definitely platform dependent. JDK 11.0.12 on my MacOS did not show
> warnings. JDK 11.0.11 on my linux workstation did show warnings in the
> euclidean module.
>
> Java. Build once, run anywhere, but with variations.
>
> These are not warnings about private @value tags. These are
> incorrect @inheritDoc:
>
> 6 warnings
> [WARNING] Javadoc Warnings
> [WARNING]
> /tmp/commons-geometry-1.0-rc4/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/twod/ReverseRay.java:181:
> warning - @inheritDoc used but splitOnIntersection(Line, Vector2D) does not
> override or implement any method.
> [WARNING]
> /tmp/commons-geometry-1.0-rc4/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/twod/ReverseRay.java:181:
> warning - @inheritDoc used but splitOnIntersection(Line, Vector2D) does not
> override or implement any method.
> [WARNING]
> /tmp/commons-geometry-1.0-rc4/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/twod/ReverseRay.java:181:
> warning - @inheritDoc used but splitOnIntersection(Line, Vector2D) does not
> override or implement any method.
> [WARNING]
> /tmp/commons-geometry-1.0-rc4/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/twod/ReverseRay.java:181:
> warning - @inheritDoc used but splitOnIntersection(Line, Vector2D) does not
> override or implement any method.
> [WARNING]
> /tmp/commons-geometry-1.0-rc4/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/twod/ReverseRay.java:181:
> warning - @inheritDoc used but splitOnIntersection(Line, Vector2D) does not
> override or implement any method.
> [WARNING]
> /tmp/commons-geometry-1.0-rc4/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/twod/ReverseRay.java:181:
> warning - @inheritDoc used but splitOnIntersection(Line, Vector2D) does not
> override or implement any method.
>
> I do not see warnings in other modules.
>
> These are the same warnings that Gilles reported. But on closer inspection
> it is the same warning 6 times. The line in question in ReverseRay does
> correctly override a method. So this is a bug in the javadoc tool on the
> linux platform. This explains why I did not see it on another build env.
> Because it is not a javadoc issue but an issue with the javadoc tool.
>
> If I run this with JDK 8 (1.8.0_241) on the same linux machine then I do
> not see the warnings in this or any other module.
>
> Alex
>
>
> On Thu, 19 Aug 2021 at 15:34, Matt Juntunen 
> wrote:
>
> > The warnings about the unknown references seem to be caused by using
> > the @value tag to reference the value of a private constant. In my
> > experience, they only appear on JDK 8 and not 11+. I consider this
> > usage worth the warning since it ensures that the value given in the
> > docs actually matches what's in the code.
> >
> > Regards,
> > Matt J
> >

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

Re: [VOTE] Release Apache Commons Geometry (full distribution) 1.0 based on RC4

[Matt Juntunen]

The warnings about the unknown references seem to be caused by using
the @value tag to reference the value of a private constant. In my
experience, they only appear on JDK 8 and not 11+. I consider this
usage worth the warning since it ensures that the value given in the
docs actually matches what's in the code.

Regards,
Matt J

On Thu, Aug 19, 2021 at 9:51 AM Gilles Sadowski  wrote:
>
> Le jeu. 19 août 2021 à 15:15, Alex Herbert  a écrit 
> :
> >
> > On Thu, 19 Aug 2021 at 14:00, Gilles Sadowski  wrote:
> >
> > > SNIP
> > > * Build OK (using Java 8).  But Javadoc warnings (cf. previous message
> > > about RC3) are still present (not sure whether that should have been
> > > fixed).[1]
> > >
> >
> > Q. Which maven command do you use to see these warnings?
>
> $ JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ mvn package javadoc:javadoc
>
> Excerpt of output:
> ---CUT---
> [...]
> 11 warnings
> [WARNING] Javadoc Warnings
> [WARNING] 
> /home/gilles/devel/java/apache/release_check/commons-geometry-1.0-rc4/commons-geometry-io-euclidean/src/main/java/org/apache/commons/geometry/io/euclidean/threed/obj/ObjBoundaryWriteHandler3D.java:82:
> warning - #DEFAULT_LINE_SEPARATOR (referenced by @value tag) is an
> unknown reference.
> [WARNING] 
> /home/gilles/devel/java/apache/release_check/commons-geometry-1.0-rc4/commons-geometry-io-euclidean/src/main/java/org/apache/commons/geometry/io/euclidean/threed/obj/ObjBoundaryWriteHandler3D.java:114:
> warning - #DEFAULT_MESH_BUFFER_BATCH_SIZE (referenced by @value tag)
> is an unknown reference.
> [WARNING] 
> /home/gilles/devel/java/apache/release_check/commons-geometry-1.0-rc4/commons-geometry-io-euclidean/src/main/java/org/apache/commons/geometry/io/euclidean/threed/obj/ObjBoundaryWriteHandler3D.java:124:
> warning - #DEFAULT_MESH_BUFFER_BATCH_SIZE (referenced by @value tag)
> is an unknown reference.
> [...]
> ---CUT---
>
> > Using JDK 8 or 11 and 'mvn javadoc:javadoc' or 'mvn site' I do not see any
> > warnings.
>
> $ JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ mvn --version
> Apache Maven 3.6.0
> Maven home: /usr/share/maven
> Java version: 1.8.0_292, vendor: Oracle Corporation, runtime:
> /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.19.0-16-amd64", arch: "amd64", family: "unix"
>
> $ /usr/lib/jvm/java-8-openjdk-amd64/bin/java -version
> openjdk version "1.8.0_292"
> OpenJDK Runtime Environment (build 1.8.0_292-8u292-b10-0+deb9u1-b10)
> OpenJDK 64-Bit Server VM (build 25.292-b10, mixed mode)
>
> >
> > I've only tried one platform and this may be JDK and/or platform specific.
> > I'd like to know as the warnings are helpful to correct documentation
> > issues.
>
> Using Java 11:
>
> $ JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64/ mvn package javadoc:javadoc
>
> Excerpt:
> ---CUT---
> [...]
> 6 warnings
> [WARNING] Javadoc Warnings
> [WARNING] 
> /home/gilles/devel/java/apache/release_check/commons-geometry-1.0-rc4/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/twod/ReverseRay.java:181:
> warning - @inheritDoc used but splitOnIntersection(Line, Vector2D)
> does not override or implement any method.
> [WARNING] 
> /home/gilles/devel/java/apache/release_check/commons-geometry-1.0-rc4/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/twod/ReverseRay.java:181:
> warning - @inheritDoc used but splitOnIntersection(Line, Vector2D)
> does not override or implement any method.
> [...]
> ---CUT---
>
> But the other warnings (about "unknown reference") are gone; so indeed, is
> this a newer Javadoc feature?
>
> Thanks,
> Gilles
>
> >
> > Alex
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [VOTE] Release Apache Commons Geometry (full distribution) 1.0 based on RC4

[Matt Juntunen]

Ok. Here is what I'd like to do:
- Continue with the vote on rc4 and release as-is if the vote passes.
- Update the geometry master branch to remove the docs folder from the
binary release package. This will fix the issue for future releases.
- Update other commons multi-module projects (rng, numbers,
statistics, math) with the same fix in order to ensure consistency
between projects.

My reasons for wanting to continue the vote on this rc are as follows:
- I have need of a full commons-geometry release for other projects.
- I have a small window of time in my schedule right now to perform
the release. If another rc is needed, it might be several weeks before
I'm able to create one.
- Previous commons projects have been released with this issue (e.g.
rng 1.3 [1], 1.2 [2], ...) with no reported user impact I am aware of.
All of the project documentation is available through other channels.

Regards,
Matt J

[1] https://dist.apache.org/repos/dist/release/commons/rng
[2] https://archive.apache.org/dist/commons/rng/binaries/

On Wed, Aug 18, 2021 at 8:10 AM Gilles Sadowski  wrote:
>
> Le mer. 18 août 2021 à 01:47, Matt Juntunen
>  a écrit :
> >
> > I agree. So, where does this leave us for this RC?
>
> If there is no blocker, it's up to you to decide...
>
> > -Matt
> >
> > On Tue, Aug 17, 2021 at 5:48 PM Gilles Sadowski  
> > wrote:
> > >
> > > Hello.
> > >
> > > IIUC the binaries are for "convenience" (although it is certainly *more*
> > > convenient to rely on ivy/maven/whatever), and there is no mandatory
> > > contents.
> > > Hence I agree that anything duplicate or half-broken should be left out.
> > >
> > > Regards,
> > > Gilles
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [VOTE] Release Apache Commons Geometry (full distribution) 1.0 based on RC4

[Matt Juntunen]

I agree. So, where does this leave us for this RC?
-Matt

On Tue, Aug 17, 2021 at 5:48 PM Gilles Sadowski  wrote:
>
> Hello.
>
> IIUC the binaries are for "convenience" (although it is certainly *more*
> convenient to rely on ivy/maven/whatever), and there is no mandatory
> contents.
> Hence I agree that anything duplicate or half-broken should be left out.
>
> Regards,
> Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [VOTE] Release Apache Commons Geometry (full distribution) 1.0 based on RC4

[Matt Juntunen]

I agree that this issue should be addressed. However, is this
something that needs to be done for this release, especially
considering that this is a long-standing issue and the documentation
in question is accessible in other locations?

Regards,
Matt J

On Tue, Aug 17, 2021 at 10:47 AM Alex Herbert  wrote:
>
> On Tue, 17 Aug 2021 at 13:18, Alex Herbert  wrote:
>
> >
> >
> > On Tue, 17 Aug 2021, 12:43 Gilles Sadowski,  wrote:
> >
> >> Hello.
> >>
> >> Le mar. 17 août 2021 à 11:58, Alex Herbert  a
> >> écrit :
> >> >
> >> > Hi,
> >> >
> >> > I am sorry to report another issue. This is a long running one that has
> >> > previously been unnoticed in releases.
> >> >
> >> > Looking inside the binary distributions I believe that the intention is
> >> to
> >> > provide documentation along with the binary jars.
> >> >
> >> > On a single module project such as lang this is provided as the javadoc
> >> > directory.
> >> >
> >> > In our released multi-module projects (rng, numbers) this has been
> >> provided
> >> > as the site directory. However this is not actually packaging the
> >> javadocs.
> >>
> >> Is there something wrong with (e.g. for [RNG] v1.3):
> >>
> >> https://repo1.maven.org/maven2/org/apache/commons/commons-rng-simple/1.3/commons-rng-simple-1.3-javadoc.jar
> >> ?
> >>
> >
> > The jars released to maven are ok.
> >
> > I am discussing the binary release that you download. The one that ends
> > with .tar.gz or .zip.
> >
> > If you obtain it and unpack it there are all the package jar files and
> > then a directory inside called docs. It is what should be in there that I
> > am discussing.
> >
> > Currently it contains part of the site. I think it should contain the
> > javadoc for all the binary jars. This is what is done for a single module
> > release such as Lang.
> >
>
> Is there a specification of what should be in a binary release? For example:
>
> commons-rng-1.3-bin.tar.gz
>
> This is 13M. If unpacked it is 44M. It has jars for the class files, the
> source and the javadoc. Then it has part of the site which is 33M when
> unpacked.
>
> If the intention is to include the javadoc then this can be obtained by
> extracting the javadoc jar files. So including the javadoc as an additional
> folder is duplicating information.
>
> In the case of commons-lang it contains jars as above but also the jars for
> the test source and classes:
>
> CONTRIBUTING.md
>
> LICENSE.txt
>
> NOTICE.txt
>
> README.md
>
> RELEASE-NOTES.txt
>
> apidocs/
>
> commons-lang3-3.12.0-javadoc.jar
>
> commons-lang3-3.12.0-sources.jar
>
> commons-lang3-3.12.0-test-sources.jar
>
> commons-lang3-3.12.0-tests.jar
>
> commons-lang3-3.12.0.jar
>
> The apidocs directory is the output of the javadoc command. If I extract
> the commons-lang3-3.12.0-javadoc.jar then I get the same folder with a few
> differences:
>
> diff apidocs/ tmp/
>
> Only in tmp/: META-INF
>
> Common subdirectories: apidocs/org and tmp/org
>
> Only in apidocs/: src-html
>
> So including the apidocs directory seems to be wasteful duplication.
>
> Perhaps we should either:
>
> - include the user guide in the binary release
> - not include anything other than the jar files
>
> Including part of the site is not helpful as it is incomplete and cannot be
> browsed. Including a javadocs directory is duplication. But for a
> multi-module project it can be created as an aggregate javadoc for the
> entire release. This has some value if it is not included anywhere else
> (i.e. as another jar in the binary archive).
>
> Alex

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

[VOTE] Release Apache Commons Geometry (full distribution) 1.0 based on RC4

[Matt Juntunen]

We have completed initial development work on Apache Commons Geometry,
so I would like to release Apache Commons Geometry (full distribution)
1.0.

Apache Commons Geometry (full distribution) 1.0 RC4 is available for
review here:
https://dist.apache.org/repos/dist/dev/commons/geometry/1.0-RC4
(svn revision 49526)

The Git tag commons-geometry-1.0-rc4 commit for this RC is
5326851864f93a486409562628afaaa485b6d99f which you can browse here:

https://gitbox.apache.org/repos/asf?p=commons-geometry.git;a=commit;h=5326851864f93a486409562628afaaa485b6d99f
You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-geometry.git
--branch commons-geometry-1.0-rc4 commons-geometry-1.0-rc4

Maven artifacts are here:
https://repository.apache.org/content/repositories/orgapachecommons-1566/

These are the artifacts and their hashes:

#Release SHA-512s
#Mon Aug 16 21:52:18 EDT 2021
commons-geometry-1.0-bin.tar.gz=b170b25f0c4c7837a51c8c3b37aa970c755c5610b16e6afa82f4cfea6dfa14f347366932e4e0ded921150ad4ad349f1d16661934925da6ece7253599fbd90cf0
commons-geometry-1.0-bin.zip=3a1c4de02f684d9837ee3284b3a35bac2369d3ea9994354218bcc0d3480330c174054b536dc02104b55a3dadee91c56a66742dd830f19dbdee5f765faf1ec596
commons-geometry-1.0-src.tar.gz=ad2c89958a3a6278135b2c820bc5c6d97edc49ea8dd119c44c49e764248e068ff0404b04cb620d0f10a7172b69ee0907f39483119c1fcd695ffe58f4c0d3731a
commons-geometry-1.0-src.zip=45c467545a84347b89319077c5c1221a5e908894a32f61f713909b2905d006de89cf4a73dc99b29b31c01c2fa28a73f71bd4ff4d530f2264a06c6a118a02b8ad

(no need for .asc hashes!)

I have tested this with ***'mvn clean install site'*** using:
***
Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
2018-02-24T14:49:05-05:00)
Maven home: /home/matt/tools/maven/apache-maven-3.5.3
Java version: 1.8.0_292, vendor: Private Build
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.4.0-80-generic", arch: "amd64", family: "unix"

Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
2018-02-24T14:49:05-05:00)
Maven home: /home/matt/tools/maven/apache-maven-3.5.3
Java version: 11.0.2, vendor: Oracle Corporation
Java home: /home/matt/lang/java/jdk-11.0.2
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.4.0-80-generic", arch: "amd64", family: "unix"

Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
2018-02-24T14:49:05-05:00)
Maven home: /home/matt/tools/maven/apache-maven-3.5.3
Java version: 16.0.1, vendor: AdoptOpenJDK
Java home: /home/matt/lang/java/jdk-16.0.1+9
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.4.0-80-generic", arch: "amd64", family: "unix"

Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: C:\Users\matt\tools\apache-maven-3.6.3-bin\apache-maven-3.6.3\bin\..
Java version: 1.8.0_242, vendor: AdoptOpenJDK, runtime: C:\Program
Files\AdoptOpenJDK\jdk-8.0.242.08-hotspot\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
***

Details of changes since 1.0-beta1 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/geometry/1.0-RC4/RELEASE-NOTES.txt

Site:
https://home.apache.org/~mattjuntunen/commons-geometry-1.0-RC4-site/
(note some *relative* links are broken and the 1.0 directories are
not yet created - these will be OK once the site is deployed.)

CLIRR Report:
N/A

JApiCmp Report:
N/A

RAT Report:

https://home.apache.org/~mattjuntunen/commons-geometry-1.0-RC4-site/rat-report.html

KEYS:
  https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 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
==

These guidelines are NOT complete.

Requirements: Git, Java, Maven.

You can validate a release from a release candidate (RC) tag as follows.

1) Clone and checkout the RC tag

git clone https://gitbox.apache.org/repos/asf/commons-geometry.git
--branch commons-geometry-1.0-rc4 commons-geometry-1.0-rc4
cd commons-geometry-1.0-rc4

2) Check Apache licenses

This step is not required if the site includes a RAT report page which
you then must check.

mvn apache-rat:check

3) Check binary compatibility

Older components still use Apache Clirr:

This step is not required if the site includes a Clirr report page
which you then must check.

mvn clirr:check

Newer components use JApi

Re: [CANCEL][VOTE] Release Apache Commons Geometry (full distribution) 1.0 based on RC3

[Matt Juntunen]

I'm cancelling this vote again to address some of the issues that Alex
found, particularly the method naming convention issue.

Alex,
The behavior you described for the AbstractNode.depth() method is as
designed. It is not sufficient for a node to not have a parent in
order to be considered a root node; it must have been explicitly set
as the root in the parent tree. This is done with the
AbstractBSPTree.setRoot() method, which calls AbstractNode.makeRoot()
and initializes the depth to 0.

I've addressed some of the issues you mentioned in a new PR [1].
Please take a look and let me know if you think it's good to go. If
so, I can try to get another RC out today.

Regards,
Matt J

[1] https://github.com/apache/commons-geometry/pull/181

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

[VOTE] Release Apache Commons Geometry (full distribution) 1.0 based on RC3

[Matt Juntunen]

We have completed initial development work on Apache Commons Geometry,
so I would like to release Apache Commons Geometry (full distribution)
1.0.

Apache Commons Geometry (full distribution) 1.0 RC3 is available for
review here:
https://dist.apache.org/repos/dist/dev/commons/geometry/1.0-RC3
(svn revision 49503)

The Git tag commons-geometry-1.0-rc3 commit for this RC is
aad4aa0b860097b05ce5bb193f47d42f93083ff5 which you can browse here:

https://gitbox.apache.org/repos/asf?p=commons-geometry.git;a=commit;h=aad4aa0b860097b05ce5bb193f47d42f93083ff5
You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-geometry.git
--branch commons-geometry-1.0-rc3 commons-geometry-1.0-rc3

Maven artifacts are here:
https://repository.apache.org/content/repositories/orgapachecommons-1565/

These are the artifacts and their hashes:

#Release SHA-512s
#Sat Aug 14 19:39:02 EDT 2021
commons-geometry-1.0-bin.tar.gz=43f54045c57ebd3420094b1ea64d8bac4130d0cd967e47ad9fda7b0b48dc16383f6057ecf2097fc425291ac21daf076c690807082c6096532a4691f23c1b767e
commons-geometry-1.0-bin.zip=63c66b5d715292f788c1bc083d5dfb47f0a56d2d6bd057eb568d5755104d76e31d374561ca734891fae1cfffc49d7c1f9e40ca5370a8df28d5b47a6bcdb1a91f
commons-geometry-1.0-src.tar.gz=6841f8d95aef9b73b9b181c347a50d589230fb055fafac8bfa2e94b641f9457a718539121b72061159e29faa5435ab82a74278bb4ad2d9044e920065121f2182
commons-geometry-1.0-src.zip=db0af5ceeb5f5ae34bf48b66505c27e901542461082647b734ed2590ece9f98e3ff11f5b95a421648dff362ef0d7f1a94ec78b227824287e56f76b531888386b

(no need for .asc hashes!)

I have tested this with ***'mvn clean install site'*** using:
***
Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
2018-02-24T14:49:05-05:00)
Maven home: /home/matt/tools/maven/apache-maven-3.5.3
Java version: 1.8.0_292, vendor: Private Build
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.4.0-80-generic", arch: "amd64", family: "unix"

Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
2018-02-24T14:49:05-05:00)
Maven home: /home/matt/tools/maven/apache-maven-3.5.3
Java version: 11.0.2, vendor: Oracle Corporation
Java home: /home/matt/lang/java/jdk-11.0.2
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.4.0-80-generic", arch: "amd64", family: "unix"

Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: C:\Users\matt\tools\apache-maven-3.6.3-bin\apache-maven-3.6.3\bin\..
Java version: 1.8.0_242, vendor: AdoptOpenJDK, runtime: C:\Program
Files\AdoptOpenJDK\jdk-8.0.242.08-hotspot\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
***

Details of changes since 1.0-beta1 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/geometry/1.0-RC3/RELEASE-NOTES.txt

Site:
https://home.apache.org/~mattjuntunen/commons-geometry-1.0-RC3-site/
(note some *relative* links are broken and the 1.0 directories are
not yet created - these will be OK once the site is deployed.)

CLIRR Report:
N/A

JApiCmp Report:
N/A

RAT Report:

https://home.apache.org/~mattjuntunen/commons-geometry-1.0-RC3-site/rat-report.html

KEYS:
  https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thank you,

Matt Juntunen,
Release Manager (using key 7DD53AEFEDF1C3D392B51EBE346F4FCECFB70B1A)

The following is intended as a helper and refresher for reviewers.

Validating a release candidate
==

These guidelines are NOT complete.

Requirements: Git, Java, Maven.

You can validate a release from a release candidate (RC) tag as follows.

1) Clone and checkout the RC tag

git clone https://gitbox.apache.org/repos/asf/commons-geometry.git
--branch commons-geometry-1.0-rc3 commons-geometry-1.0-rc3
cd commons-geometry-1.0-rc3

2) Check Apache licenses

This step is not required if the site includes a RAT report page which
you then must check.

mvn apache-rat:check

3) Check binary compatibility

Older components still use Apache Clirr:

This step is not required if the site includes a Clirr report page
which you then must check.

mvn clirr:check

Newer components use JApiCmp with the japicmp Maven Profile:

This step is not required if the site includes a JApiCmp report page
which you then must check.

mvn install -DskipTests -P japicmp japicmp:cmp

4) Build the package

mvn -V clean package

You can record the Maven and Java version produced by -V in your VOTE reply.
To gather OS information from a command line:
Windows: ver
Linux: uname -a

5) Build the site for

Re: [VOTE][CANCELLED] Release Apache Commons Geometry (full distribution) 1.0 based on RC1

[Matt Juntunen]

In addition to the issues that Alex found, I also noticed that the
commons-geometry-io-euclidean module was completely missing NOTICE and
LICENSE files. So, I'm going to cancel this vote and try again with
RC2.

Unless someone thinks it is a blocker, I'm going to defer any changes
related to the PMD reports until after the release. All of the issues
are priority 3 and below.

Regards,
Matt J

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

Re: [VOTE] Release Apache Commons Geometry (full distribution) 1.0 based on RC1

[Matt Juntunen]

Hi Alex,

Thanks for catching these. Do you consider these a deal breaker for this rc?

-Matt

On Thu, Aug 12, 2021 at 6:52 PM Alex Herbert  wrote:
>
> Hi Matt,
>
> I've just started looking at this so I will not vote yet but I have found a
> few issues.
>
> I did not have 'svn' on my laptop so running 'mvn site' fails. I installed
> 'svn' and then I get the issue that the entire site is downloaded for all
> the modules. I solved this problem in RNG by altering the command to only
> do a top level svn checkout for the parent directory. This is done in the
> pom profiles 'is-child-module', 'setup-checkout' and 'clean-checkout'. It
> fixes the large download of the site. I've just pushed a fix to correct
> the site download if svn is not available.
>
> The NOTICE.txt file has 2020 as the year.
>
> I'll try the build on a few machines and let you know if there are any
> further issues.
>
> Alex
>
>
>
> On Thu, 12 Aug 2021 at 16:41, Matt Juntunen 
> wrote:
>
> > We have completed initial development work on Apache Commons Geometry,
> > so I would like to release Apache Commons Geometry (full distribution)
> > 1.0.
> >
> > Apache Commons Geometry (full distribution) 1.0 RC1 is available for
> > review here:
> > https://dist.apache.org/repos/dist/dev/commons/geometry/1.0-RC1
> > (svn revision 49476)
> >
> > The Git tag commons-geometry-1.0-rc1 commit for this RC is
> > 61ea6625233d2e46b805f009ec9e6cb6340d5e65 which you can browse here:
> >
> > https://gitbox.apache.org/repos/asf?p=commons-geometry.git;a=commit;h=61ea6625233d2e46b805f009ec9e6cb6340d5e65
> > You may checkout this tag using:
> > git clone https://gitbox.apache.org/repos/asf/commons-geometry.git
> > --branch
> > <https://gitbox.apache.org/repos/asf/commons-geometry.git--branch>
> > commons-geometry-1.0-rc1 commons-geometry-1.0-rc1
> >
> > Maven artifacts are here:
> >
> > https://repository.apache.org/content/repositories/orgapachecommons-1561/
> >
> > These are the artifacts and their hashes:
> >
> > #Release SHA-512s
> > #Wed Aug 11 23:20:33 EDT 2021
> >
> > commons-geometry-1.0-bin.tar.gz=4e8fac99bdc31e9eeef76b614cbbfe7b2ab3db75578f4ab302c7d4b9ec70330c6be0bd8fd5683fd131784eb79b8e5547f954f4e24b3c54d778fc18cea53f49f3
> >
> > commons-geometry-1.0-bin.zip=766a1f6c5b9441c0eed3ae76a4b5c102c708b2b7cd9b3366b1cacdff2fd7d33abb06948cc49b5e80e8af3e06c7eb24b24d26e0c537260955eb97ce8307d505c2
> >
> > commons-geometry-1.0-src.tar.gz=6232b8e88589e85b95e4a31ab89b45af97ec09df71f350d2de56197035f3a9b5cfa9ac1e682282c7417a8ccbb7f31ccefb9c903a38ee4e9ebb796777563cdf28
> >
> > commons-geometry-1.0-src.zip=5bae090d946e0d43b53108b6e9f3edf07dcff74932ea0f9ec8f5c4b9848ca559c434967fb00b0fc90e287d699e4243f0def5764e3eb5decc1abf4f2ecfefc238
> >
> >
> > (no need for .asc hashes!)
> >
> > I have tested this with ***'mvn clean install site'*** using:
> > ***
> > Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
> > 2018-02-24T14:49:05-05:00)
> > Maven home: /home/matt/tools/maven/apache-maven-3.5.3
> > Java version: 1.8.0_292, vendor: Private Build
> > Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "linux", version: "5.4.0-80-generic", arch: "amd64", family:
> > "unix"
> >
> > Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> > Maven home: C:\Users\mjuntune\tools\apache-maven-3.6.3\bin\..
> > Java version: 1.8.0_291, vendor: Oracle Corporation, runtime:
> > C:\Program Files\Java\jdk1.8.0_291\jre
> > Default locale: en_US, platform encoding: Cp1252
> > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> > ***
> >
> > Details of changes since 1.0-beta1 are in the release notes:
> >
> > https://dist.apache.org/repos/dist/dev/commons/geometry/1.0-RC1/RELEASE-NOTES.txt
> >
> > Site:
> > https://home.apache.org/~mattjuntunen/commons-geometry-1.0-RC1-site/
> > (note some *relative* links are broken and the 1.0 directories are
> > not yet created - these will be OK once the site is deployed.)
> >
> > CLIRR Report (compared to ${commons.bc.version}):
> > N/A
> >
> > JApiCmp Report (compared to ${commons.bc.version}):
> > N/A
> >
> > RAT Report:
> >
> > https://home.apache.org/~mattjuntunen/commons-geometry-1.0-RC1-site/rat-report.html
> >
> > KEYS:
> >   https://www.apache.org/dist/commons/KEYS
> >
> > Please review 

[VOTE] Release Apache Commons Geometry (full distribution) 1.0 based on RC1

[Matt Juntunen]

We have completed initial development work on Apache Commons Geometry,
so I would like to release Apache Commons Geometry (full distribution)
1.0.

Apache Commons Geometry (full distribution) 1.0 RC1 is available for
review here:
https://dist.apache.org/repos/dist/dev/commons/geometry/1.0-RC1
(svn revision 49476)

The Git tag commons-geometry-1.0-rc1 commit for this RC is
61ea6625233d2e46b805f009ec9e6cb6340d5e65 which you can browse here:

https://gitbox.apache.org/repos/asf?p=commons-geometry.git;a=commit;h=61ea6625233d2e46b805f009ec9e6cb6340d5e65
You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-geometry.git
--branch commons-geometry-1.0-rc1 commons-geometry-1.0-rc1

Maven artifacts are here:
https://repository.apache.org/content/repositories/orgapachecommons-1561/

These are the artifacts and their hashes:

#Release SHA-512s
#Wed Aug 11 23:20:33 EDT 2021
commons-geometry-1.0-bin.tar.gz=4e8fac99bdc31e9eeef76b614cbbfe7b2ab3db75578f4ab302c7d4b9ec70330c6be0bd8fd5683fd131784eb79b8e5547f954f4e24b3c54d778fc18cea53f49f3
commons-geometry-1.0-bin.zip=766a1f6c5b9441c0eed3ae76a4b5c102c708b2b7cd9b3366b1cacdff2fd7d33abb06948cc49b5e80e8af3e06c7eb24b24d26e0c537260955eb97ce8307d505c2
commons-geometry-1.0-src.tar.gz=6232b8e88589e85b95e4a31ab89b45af97ec09df71f350d2de56197035f3a9b5cfa9ac1e682282c7417a8ccbb7f31ccefb9c903a38ee4e9ebb796777563cdf28
commons-geometry-1.0-src.zip=5bae090d946e0d43b53108b6e9f3edf07dcff74932ea0f9ec8f5c4b9848ca559c434967fb00b0fc90e287d699e4243f0def5764e3eb5decc1abf4f2ecfefc238


(no need for .asc hashes!)

I have tested this with ***'mvn clean install site'*** using:
***
Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
2018-02-24T14:49:05-05:00)
Maven home: /home/matt/tools/maven/apache-maven-3.5.3
Java version: 1.8.0_292, vendor: Private Build
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.4.0-80-generic", arch: "amd64", family: "unix"

Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: C:\Users\mjuntune\tools\apache-maven-3.6.3\bin\..
Java version: 1.8.0_291, vendor: Oracle Corporation, runtime:
C:\Program Files\Java\jdk1.8.0_291\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
***

Details of changes since 1.0-beta1 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/geometry/1.0-RC1/RELEASE-NOTES.txt

Site:
https://home.apache.org/~mattjuntunen/commons-geometry-1.0-RC1-site/
(note some *relative* links are broken and the 1.0 directories are
not yet created - these will be OK once the site is deployed.)

CLIRR Report (compared to ${commons.bc.version}):
N/A

JApiCmp Report (compared to ${commons.bc.version}):
N/A

RAT Report:

https://home.apache.org/~mattjuntunen/commons-geometry-1.0-RC1-site/rat-report.html

KEYS:
  https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 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
==

These guidelines are NOT complete.

Requirements: Git, Java, Maven.

You can validate a release from a release candidate (RC) tag as follows.

1) Clone and checkout the RC tag

git clone https://gitbox.apache.org/repos/asf/commons-geometry.git
--branch commons-geometry-1.0-rc1 commons-geometry-1.0-rc1
cd commons-geometry-1.0-rc1

2) Check Apache licenses

This step is not required if the site includes a RAT report page which
you then must check.

mvn apache-rat:check

3) Check binary compatibility

Older components still use Apache Clirr:

This step is not required if the site includes a Clirr report page
which you then must check.

mvn clirr:check

Newer components use JApiCmp with the japicmp Maven Profile:

This step is not required if the site includes a JApiCmp report page
which you then must check.

mvn install -DskipTests -P japicmp japicmp:cmp

4) Build the package

mvn -V clean package

You can record the Maven and Java version produced by -V in your VOTE reply.
To gather OS information from a command line:
Windows: ver
Linux: uname -a

5) Build the site for a single module project

Note: Some plugins require the components to be installed instead of packaged.

mvn site
Check the site reports in:
- Windows: target\site\index.html
- Linux: target/site/index.html

6) Build the site for a multi-module project

mvn site
mvn site:stage
Check the site reports

Re: [geometry] 1.0 release (take 2)

[Matt Juntunen]

FYI, I'm planning to start the geometry release process within the
next couple of days instead of waiting for the RNG release as
mentioned previously. (Geometry only uses RNG for unit tests and
benchmarks.) The reasons for this change of plans is that (1) I have
need of the code in other projects and (2) I have time now to do the
release but will most likely not later on. Please let me know if you
have any objections.

Regards,
Matt J

On Mon, Aug 2, 2021 at 7:25 AM Alex Herbert  wrote:
>
> On Mon, 2 Aug 2021 at 02:32, Matt Juntunen 
> wrote:
>
> >
> > > Then, as a matter of preference, I'd still suggest that "Commons RNG"
> > > be released first (if the latter's next release is pending).
> >
> > Ok. Any thoughts on a timeline for that?
> >
>
> I am currently looking at it.
>
> The dryRun build of the release profile now works under JDK 11.0.11. This
> is good. Previously JDK 11 complained about the JPMS modules using code
> from packages in the unnamed module and this errored the build. It had to
> be released using JDK 9. Now the latest JDK has a more lenient javadoc tool
> and the warnings are printed but it does not fail the build.
>
> I am going to try updating the modules to use Java 11 in-place of Java 9
> and see if that works. It would be preferable to release the example JPMS
> modules built using the first LTS version to support modules (i.e. JDK 11
> not not JDK 9).
>
> Alex

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

Re: [all] Binaries for example modules

[Matt Juntunen]

> Advertising
> the examples at a higher level in the project site is better, so adding
> them to the user guide is an appropriate place. The question then is should
> the higher location point the user to the module site index, recommend
> downloading the source release which contains all the examples (and not
> having the module site published), or both.

I would say both.

> I do not think pushing the artifacts to Maven Central is useful

+1. I think we're all agreed on this point.

-Matt J

On Sun, Aug 8, 2021 at 5:38 PM Alex Herbert  wrote:
>
> On Fri, 6 Aug 2021 at 04:01, Gilles Sadowski  wrote:
>
> > Le ven. 6 août 2021 à 04:01, Matt Juntunen  a
> > écrit :
> > >
> > > Gilles,
> > >
> > > > I do _not_ ask any work to be done in order to complicate the release
> > > > process and/or review.
> > > > My question was (cf. above and the other thread) whether singling out
> > > > the "examples" module has any benefit (apart from saving a few bytes
> > > > on Maven Central).
> > >
> > > Yes, I believe it is beneficial. If nothing else, it keeps maven
> > > central and the project site uncluttered and reduces the chance of
> > > user confusion.
> >
> > I do not see where the problem is supposed to be (with Maven Central).
> > But, either way, it's not worth fighting over it, as long as the examples
> > are kept in sync with the code (and this is done at the lastest as part
> > of the current release process).  [The counter-example is "Commons
> > Math", where the code examples were not kept up to date with the
> > main code...]
> > For the site, I believe that the examples should be there, as they are
> > show-cases (for users!) of fully-working applications.[1]
> >
>
> I do not think that the layout of the site for maven modules is very
> friendly for browsing the source. You are required to traverse down the
> hierarchy to the module site index, then click the project reports link
> then either the javadoc or xref reports. It takes a lot of finding and may
> not be found at all by a new user of the modular site layout. Advertising
> the examples at a higher level in the project site is better, so adding
> them to the user guide is an appropriate place. The question then is should
> the higher location point the user to the module site index, recommend
> downloading the source release which contains all the examples (and not
> having the module site published), or both.
>
> I do not think pushing the artifacts to Maven Central is useful as the
> applications are either developer testing tools or integration test demos.
> These are not of use to be linked by a third party as a dependency, and
> given they have no binary compatibility guarantee it would be unwise to
> depend on them anyway.
>
>
> >
> > Gilles
> >
> > [1] See e.g.
> > https://commons.apache.org/proper/commons-rng/commons-rng-examples/commons-rng-examples-quadrature/xref/index.html
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >

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

Re: [all] Binaries for example modules

[Matt Juntunen]

Gilles,

> I do _not_ ask any work to be done in order to complicate the release
> process and/or review.
> My question was (cf. above and the other thread) whether singling out
> the "examples" module has any benefit (apart from saving a few bytes
> on Maven Central).

Yes, I believe it is beneficial. If nothing else, it keeps maven
central and the project site uncluttered and reduces the chance of
user confusion.

-Matt J

On Thu, Aug 5, 2021 at 12:50 PM Alex Herbert  wrote:
>
> On Thu, 5 Aug 2021 at 17:23, Gilles Sadowski  wrote:
>
> > Hi.
> >
> > Le jeu. 5 août 2021 à 18:01, Alex Herbert  a
> > écrit :
> > >
> > > On Thu, 5 Aug 2021 at 14:07, Gilles Sadowski 
> > wrote:
> > >
> > > > Le jeu. 5 août 2021 à 14:08, Gary Gregory  a
> > > > écrit :
> > > > >
> > > > > I agree with Matt.
> > > >
> > > > Nobody seems to disagree (about not providing convenience *binaries*
> > > > of the examples).
> > > > My point was that the examples _must_ be part of the (source) release
> > > > (with the caveat that they are not subject to BC), in the same way that
> > > > unit tests are, because they could sometimes exercise the code in a way
> > > > which the unit tests do not.
> > > > Maybe I misunderstood Matt's proposal, which I thought was was to not
> > > > release the examples (i.e. leaving them out of the release branch).
> > > >
> > >
> > > If the release profile in the POM omits the examples modules then they
> > will
> > > not be released as binary jars to nexus, and the modules are omitted from
> > > the site generation. The contents of the distribution release binary
> > (zip,
> > > tar.gz) are specified separately. So these can include all the source
> > text
> > > files from the examples.
> > >
> > > However if the examples modules are not in the POM hierarchy then the
> > > binaries will not be built from the source as part of the release
> > process.
> > > It is possible to include the modules and skip the site generation for
> > the
> > > maven-site-plugin. I am not sure about skipping the maven-release-plugin.
> > > It may be possible using the dryRun parameter but I would have to
> > > investigate.
> > >
> > > If the build of the examples cannot be set-up to be verified during the
> > > release process then this should be verified by the RM and any reviewers
> > of
> > > the release to ensure the examples do build from the source distribution.
> > >
> > > In the case of RNG this could involve adding a step to the release guide
> > to
> > > state that applications in all the example modules should be run to
> > ensure
> > > they compile with the API from the released code. The same can be added
> > to
> > > guidelines in the VOTE e-mail.
> > >
> > > Would this cover your requirement that the examples code is exercised?
> >
> > I do _not_ ask any work to be done in order to complicate the release
> > process and/or review.
> > My question was (cf. above and the other thread) whether singling out
> > the "examples" module has any benefit (apart from saving a few bytes
> > on Maven Central).
> >
>
> I've just pushed an update to RNG to add more details on how to run the
> examples. I will look at preparing a release without the examples modules
> in the next few days. Ideally I would like to ensure the process builds the
> binaries just to check it is possible but not add them Maven central or the
> limited module reports to the site. Otherwise I am fine with a manual
> verification step (that can be scripted) just to build and run each example.
>
> The examples are built using Jenkins so they should be kept current and
> able to compile. Running them is not something done by the CI build.
>
> Alex
>
>
>
> >
> > Best,
> > Gilles
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >

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

Re: [all] Binaries for example modules

[Matt Juntunen]

> I think it is preferable to perform the release using only the public API
> modules. The examples will be released in the source tarball.

+1

> The question is whether the examples require some additional advertisement
> on the main website, for example an additional page, or section in the user 
> guide, to
> describe what examples are available, how to build them locally and why you
> might want to run them. Otherwise they will just be left as a developer's
> secret hidden in the source release.

IMO, a section in the user guide listing the example modules available
[1] along with
instructions for building (e.g. what maven profiles to include) would
be sufficient.

-Matt J

[1] 
https://commons.apache.org/proper/commons-rng/commons-rng-examples/index.html

On Thu, Aug 5, 2021 at 6:11 AM Alex Herbert  wrote:
>
> On Thu, 5 Aug 2021 at 01:40, Gilles Sadowski  wrote:
>
> > Le jeu. 5 août 2021 à 01:46, sebb  a écrit :
> > >
> > > On Wed, 4 Aug 2021 at 13:38, Gilles Sadowski 
> > wrote:
> > > >
> > > > Hi.
> > > >
> > > > Le mer. 4 août 2021 à 04:27, Matt Juntunen 
> > a écrit :
> > > > >
> > > > > Hello,
> > > > >
> > > > > I apologize if this was resolved already and I missed it, but did we
> > > > > land anywhere on the issue of whether or not to release binaries of
> > > > > example code modules? I've included the example module binaries in
> > > > > previous releases of numbers and geometry but I don't think that they
> > > > > are actually useful just as binaries. Are we ok to just leave the
> > > > > example modules as code included in the source release? Also, should
> > > > > they be part of the deployed site or should that just be for the
> > > > > public API portions?
> > > >
> > > > FTR, I quote the question raised in another thread where this issue
> > > > was first mentioned:
> > > >  "[...] how can we release (some official version of) the project as
> > source
> > > >   without also releasing the (convenience) binaries for everything?"
> > >
> > > The ASF releases source.
> > >
> > > Binaries are optional.
> >
> > This has been stated in my quote (cf. "convenience").
> > The question is whether we want to complexify the release procedure
> > in order to not build the binaries for some of the source.
> > What's the gain for the RM/developers/users?
> >
>
> Looking at the modular project for RNG it may complexify the release
> procedure to not distribute the binary jars for the examples if we still
> wish to report the examples on the site using the modular site structure.
>
> Currently we include all the examples and release using the goals 'package
> site site:stage deploy'.
>
> If we omit the examples from the module hierarchy then they will not be
> included in the site. The examples will still be included in the source
> release as it creates an archive of everything from the root directory.
>
> However at present the examples in RNG do not have a useful site page. The
> page simply states a single line description and then a second line stating
> the module is not part of the public API. See the current examples overview
> page [1]. Leaving them out of the site would remove the ability to browse
> the source using the module project reports. It would remove the javadoc
> module report. The javadocs are not very informative (see [2]). IMO these
> module reports are not useful and I would drop these entirely from the site.
>
> The examples in RNG are used for testing functionality. Some of these
> examples create a runnable jar file using the shade plugin to bring in all
> the dependencies. These are the most useful part of the examples as they
> would allow an end user to run performance tests locally without having to
> build the program. However the shaded uber-jars have never been released
> and would require some licence checking to be done to see if they can be
> distributed.
>
> I think it is preferable to perform the release using only the public API
> modules. The examples will be released in the source tarball. The question
> is whether the examples require some additional advertisement on the main
> website, for example an additional page, or section in the user guide, to
> describe what examples are available, how to build them locally and why you
> might want to run them. Otherwise they will just be left as a developer's
> secret hidden in the source release.
>
> Alex
>
> [1]
> https://commons.apache.org/proper/comm

[all] Binaries for example modules

[Matt Juntunen]

Hello,

I apologize if this was resolved already and I missed it, but did we
land anywhere on the issue of whether or not to release binaries of
example code modules? I've included the example module binaries in
previous releases of numbers and geometry but I don't think that they
are actually useful just as binaries. Are we ok to just leave the
example modules as code included in the source release? Also, should
they be part of the deployed site or should that just be for the
public API portions?

Regards,
Matt J

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

Re: [geometry] 1.0 release (take 2)

[Matt Juntunen]

> We should wait for some positive feedback from the code being
> exercised by that new tool.  [I've no idea of how long is long enough.]

If I'm reading this link [1] correctly, it sounds like a few days
should be sufficient. (The fuzzers were merged in today.)

> Then, as a matter of preference, I'd still suggest that "Commons RNG"
> be released first (if the latter's next release is pending).

Ok. Any thoughts on a timeline for that?

Regards,
Matt J

[1] 
https://google.github.io/oss-fuzz/faq/#what-if-my-fuzzer-does-not-find-anything
On Sun, Aug 1, 2021 at 12:36 PM Alex Herbert  wrote:
>
> On Sun, 1 Aug 2021 at 16:25, Gilles Sadowski  wrote:
>
> > Hi.
> >
> > Le dim. 1 août 2021 à 02:57, Matt Juntunen  a
> > écrit :
> > >
> > > Hello,
> > >
> > > I've addressed a few issues since I last proposed the commons-geometry
> > > 1.0 release, namely
> > > - reducing the code smells in SonarCloud from 100+ to 8 (mostly by
> > > clearing false positives) and
> > > - removing use of checked exceptions in the IO modules (GEOMETRY-138).
> >
> > Thanks! :-)
> >
> > > I've also run fuzz testing locally on the IO modules and am pursuing
> > > integrating the project into OSS-Fuzz. So, how are we feeling about a
> > > 1.0 release?
> >
> > We should wait for some positive feedback from the code being
> > exercised by that new tool.  [I've no idea of how long is long enough.]
> >
> > Then, as a matter of preference, I'd still suggest that "Commons RNG"
> > be released first (if the latter's next release is pending).
> >
>
> I think that RNG can be released as there is nothing pending to add. I've
> updated the user guide with the latest performance tests and new API
> additions. I have not yet checked the new API to make sure all is OK with
> the new method signatures and class names.
>
> Alex

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

[geometry] 1.0 release (take 2)

[Matt Juntunen]

Hello,

I've addressed a few issues since I last proposed the commons-geometry
1.0 release, namely
- reducing the code smells in SonarCloud from 100+ to 8 (mostly by
clearing false positives) and
- removing use of checked exceptions in the IO modules (GEOMETRY-138).
I've also run fuzz testing locally on the IO modules and am pursuing
integrating the project into OSS-Fuzz. So, how are we feeling about a
1.0 release? As before, the following modules would be included:
- commons-geometry-core
- commons-geometry-euclidean
- commons-geometry-spherical
- commons-geometry-io-core
- commons-geometry-io-euclidean

Regards,
Matt J

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

Re: [Geometry] Checked exceptions

[Matt Juntunen]

I've created GEOMETRY-138 [1] to track this and discuss the technical details.
-Matt

[1] https://issues.apache.org/jira/projects/GEOMETRY/issues/GEOMETRY-138

On Sat, Jul 24, 2021 at 12:41 PM Gilles Sadowski  wrote:
>
> Le sam. 24 juil. 2021 à 18:25, Matt Juntunen
>  a écrit :
> >
> > I don't have a preference for checked or unchecked exceptions. I just
> > want it to be consistent, easy to use, and maintainable.
>
> Checked exceptions are a maintenance nightmare.
> [Some time in the future, you change the implementation so that
> it actually does not ever throw the (checked) exception; still you
> are stuck with it because it's part of the signature.]
>
> > With that
> > said, what specific changes are you picturing should be made to the
> > code here? Are you suggesting a geometry-specific exception type?
> > Should we wrap IOExceptions as runtime exceptions?
>
> Yes.
> Fine to correct JDK mistakes, not to copy them. ;-)
>
> Here is a (7 years old) post that hopefully will, once and for all, settle
> the recurring debate:
> 
> https://literatejava.com/exceptions/checked-exceptions-javas-biggest-mistake/
>
> If "TL;DR;" 2 quotes:
> ---CUT---
> [...] if your projects are still using or advocating checked exceptions,
> your skills are 5-10 years out [of] date. Java has moved on.
> ---CUT---
> ---CUT---
> For checked exceptions to be useful, however, depends on selective
> & usefully handleable (recoverable) exceptions being the only ones
> checked. You could propose that FileNotFound or failures connecting
> could be in that basket — but I/O failures reading or writing once the
> file is open, are almost completely not.
> ---CUT---
>
> Thanks,
> Gilles
>
> >
> > -Matt
> >
> > On Sat, Jul 24, 2021 at 12:11 PM Gilles Sadowski  
> > wrote:
> > >
> > > Hi.
> > >
> > > Le sam. 24 juil. 2021 à 17:01, Matt Juntunen
> > >  a écrit :
> > > >
> > > > Hello,
> > > >
> > > > > AFAICT, a precondition (max string length) is violated by the input: 
> > > > > the
> > > > error is the caller's fault (either passing a too long string, or not 
> > > > having
> > > > set an appropriate upper bound).
> > > >
> > > > This is not correct. This exception is thrown when a string token from
> > > > the input stream exceeds the maximum string token length. (The maximum
> > > > length is used to prevent invalid/malicious input from allocating an
> > > > enormous string in the JVM.) So, the error is with the input, not the
> > > > caller.
> > >
> > > There is a misunderstanding; in my statements, "caller" and "input" are
> > > used interchangeably, and synonyms for "precondition violation", IOW:
> > > "This method assumes  and , and if you call it by passing
> > > input that is not compliant, it will throw an exception".
> > > In the above sentence, a _runtime_ exception is thrown if the error
> > > is not recoverable.
> > >
> > > Note that "recoverable" would imply that the caller (*within* [Geometry])
> > > catches the (checked) exception and is able to complete the requested
> > > task.  [I don't know how that's possible in this instance (where input has
> > > been identified as wrong).]
> > >
> > > > The general principle with the geometry IO code is that IOExceptions
> > > > (which the methods in question must already declare since they
> > > > ultimately read from InputStreams) indicate an error extracting data
> > > > from the input. Possible cases include:
> > > > - network/file system errors
> > > > - parsing/syntax errors
> > > > - data conversion errors (e.g. string to double)
> > >
> > > None of those are recoverable from the POV the [Geometry] code:
> > > Parsing having failed for any of those reason will raise an exception
> > > and it's up to the caller to sort it
> > > There is no added value for this exception to be checked by the
> > > compiler.
> > > Going against currently recommended practice (cf. e.g. "Effective
> > > Java" by J. Bloch) would only be valid for BC reasons (cf. recent
> > > discussion about [Compress]).
> > >
> > > > Runtime exceptions may be thrown for other issues occurring after the
> > > > raw data has been retrieved from the file/stream, primarily if the
> > > > extracted data is not mathematically valid.
>

Re: [Geometry] Checked exceptions

[Matt Juntunen]

I don't have a preference for checked or unchecked exceptions. I just
want it to be consistent, easy to use, and maintainable. With that
said, what specific changes are you picturing should be made to the
code here? Are you suggesting a geometry-specific exception type?
Should we wrap IOExceptions as runtime exceptions?

-Matt

On Sat, Jul 24, 2021 at 12:11 PM Gilles Sadowski  wrote:
>
> Hi.
>
> Le sam. 24 juil. 2021 à 17:01, Matt Juntunen
>  a écrit :
> >
> > Hello,
> >
> > > AFAICT, a precondition (max string length) is violated by the input: the
> > error is the caller's fault (either passing a too long string, or not having
> > set an appropriate upper bound).
> >
> > This is not correct. This exception is thrown when a string token from
> > the input stream exceeds the maximum string token length. (The maximum
> > length is used to prevent invalid/malicious input from allocating an
> > enormous string in the JVM.) So, the error is with the input, not the
> > caller.
>
> There is a misunderstanding; in my statements, "caller" and "input" are
> used interchangeably, and synonyms for "precondition violation", IOW:
> "This method assumes  and , and if you call it by passing
> input that is not compliant, it will throw an exception".
> In the above sentence, a _runtime_ exception is thrown if the error
> is not recoverable.
>
> Note that "recoverable" would imply that the caller (*within* [Geometry])
> catches the (checked) exception and is able to complete the requested
> task.  [I don't know how that's possible in this instance (where input has
> been identified as wrong).]
>
> > The general principle with the geometry IO code is that IOExceptions
> > (which the methods in question must already declare since they
> > ultimately read from InputStreams) indicate an error extracting data
> > from the input. Possible cases include:
> > - network/file system errors
> > - parsing/syntax errors
> > - data conversion errors (e.g. string to double)
>
> None of those are recoverable from the POV the [Geometry] code:
> Parsing having failed for any of those reason will raise an exception
> and it's up to the caller to sort it
> There is no added value for this exception to be checked by the
> compiler.
> Going against currently recommended practice (cf. e.g. "Effective
> Java" by J. Bloch) would only be valid for BC reasons (cf. recent
> discussion about [Compress]).
>
> > Runtime exceptions may be thrown for other issues occurring after the
> > raw data has been retrieved from the file/stream, primarily if the
> > extracted data is not mathematically valid.
>
> Example (b) does the opposite: It turns a runtime exception into an
> "IOException".
>
> I note that parsing occurs _after_ reading; such that any "IOException"
> that is raised from an underlying stream should (IMO) be caught ASAP
> and wrapped in a runtime exception (to be rethrown, since the condition
> is not recoverable).
> The root cause (e.g. whether it is a parse issue or a file system issue)
> will be visible in the stack trace.  No need to spread "throws" clauses
> for that.
>
> > I feel that this separation of exception behavior between IO/format
> > errors and high-level mathematical validation is useful.
>
> I agree, but "different behaviours" can be implemented by different
> types.  This is orthogonal to "checked" vs "unchecked".
>
> > As an end
> > user of an application that uses this library, I want to know if the
> > file I provided was just plain invalid versus if it just contained a
> > wonky geometry.
>
> I'm not sure I understand the issue (it seems to me that both are
> irrecoverable).  Please provide an example that mandates checked
> exceptions.
>
> Regards,
> Gilles
>
> >
> > Regards,
> > Matt
> >
> > On Sat, Jul 24, 2021 at 8:28 AM Gilles Sadowski  
> > wrote:
> > >
> > > Hello.
> > >
> > > Somehow I missed that [Geometry] contains usage of checked exceptions.
> > > As mentioned in other threads, I have a hard time conceiving that the kind
> > > of codes we are dealing with here ever needs the concept of checked
> > > exception (in its intended usage per the _current_ Java experts, and not
> > > based on outdated practice from the time when Java advocates were hoping
> > > that checked exceptions would be the cure to all evil...).
> > >
> > > Examples:
> > >
> > > (a)
> > > ---CUT---
> > > /** Get the string col

Re: [Geometry] Checked exceptions

[Matt Juntunen]

Hello,

> AFAICT, a precondition (max string length) is violated by the input: the
error is the caller's fault (either passing a too long string, or not having
set an appropriate upper bound).

This is not correct. This exception is thrown when a string token from
the input stream exceeds the maximum string token length. (The maximum
length is used to prevent invalid/malicious input from allocating an
enormous string in the JVM.) So, the error is with the input, not the
caller.

The general principle with the geometry IO code is that IOExceptions
(which the methods in question must already declare since they
ultimately read from InputStreams) indicate an error extracting data
from the input. Possible cases include:
- network/file system errors
- parsing/syntax errors
- data conversion errors (e.g. string to double)

Runtime exceptions may be thrown for other issues occurring after the
raw data has been retrieved from the file/stream, primarily if the
extracted data is not mathematically valid.

I feel that this separation of exception behavior between IO/format
errors and high-level mathematical validation is useful. As an end
user of an application that uses this library, I want to know if the
file I provided was just plain invalid versus if it just contained a
wonky geometry.

Regards,
Matt

On Sat, Jul 24, 2021 at 8:28 AM Gilles Sadowski  wrote:
>
> Hello.
>
> Somehow I missed that [Geometry] contains usage of checked exceptions.
> As mentioned in other threads, I have a hard time conceiving that the kind
> of codes we are dealing with here ever needs the concept of checked
> exception (in its intended usage per the _current_ Java experts, and not
> based on outdated practice from the time when Java advocates were hoping
> that checked exceptions would be the cure to all evil...).
>
> Examples:
>
> (a)
> ---CUT---
> /** Get the string collected by this instance.
>  * @return the string collected by this instance
>  * @throws IOException if the string exceeds the maximum
> configured length
>  */
> public String getString() throws IOException {
> if (hasExceededMaxStringLength()) {
> throw parseError(line, col, STRING_LENGTH_ERR_MSG +
> maxStringLength);
> }
> return sb.toString();
> }
> ---CUT---
>
> AFAICT, a precondition (max string length) is violated by the input: the
> error is the caller's fault (either passing a too long string, or not having
> set an appropriate upper bound).  In any case, it is not recoverable, so
> a checked exception is ruled out.
>
> (b)
> ---CUT---
> /** Get the current token parsed as an integer.
>  * @return the current token parsed as an integer
>  * @throws IllegalStateException if no token has been read
>  * @throws IOException if the current token cannot be parsed as an integer
>  */
> public int getCurrentTokenAsInt() throws IOException {
> ensureHasSetToken();
> Throwable cause = null;
> if (currentToken != null) {
> try {
> return Integer.parseInt(currentToken);
> } catch (NumberFormatException exc) {
> cause = exc;
> }
> }
> throw unexpectedToken("integer", cause);
> }
> ---CUT---
>
> "Integer.parseInt" (JDK) complies with the rationale: a runtime exception
> is rightfully thrown on precondition failure (input cannot be parsed as an
> "integer"), and turning it into a checked exception just adds complexity
> for zero gain (such errors are all the same non-recoverable).
>
> For the parser to be robust (in the sense of not crashing the code without a
> message that correctly identifies the cause of the failure), there is no need
> for checked exceptions.
>
> IMO, for any new code, the introduction of a checked exception should be
> accompanied by an example demonstrating what the library does in order
> to _recover_.  [If it doesn't to anything (other than throw, rethrow, or log 
> an
> error message) then an unchecked exception should be used instead.]
>
>
> Regads,
> Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [geometry] 1.0 release

[Matt Juntunen]

Alex, you are correct that a large number of the SonarQube issues can
be closed as "won't fix". I've opened INFRA-22130 [1] so I can get
admin access to make those changes.

Gilles, what do you picture as required in order for commons-geometry
to be released? Do you see fuzz-testing as a blocker? If so, how much
fuzz testing do you think is needed before the release?

Regards,
Matt

[1] https://issues.apache.org/jira/browse/INFRA-22130

On Wed, Jul 21, 2021 at 10:36 AM Alex Herbert  wrote:
>
> On Wed, 21 Jul 2021 at 13:34, Gilles Sadowski  wrote:
>
> >
> > I'm not really pushing for either of the above two.  Instead, we
> > we should try and clean up everything[1][2] before the first stable
> > release.
> >
>
> With regard to SonarCloud, Matt are you able to administer the issues on
> the commons projects?
>
> If not then you can request that your github ID be added as an
> administrator of the commons projects on sonarcloud. The ticket where I did
> this is [INFRA-19172]. I asked for RNG but I have access to all the
> projects.
>
> I have not looked at the Geometry sonar report beyond seeing that it has a
> lot of issues. I am sure that many of these can be bulk closed as won't fix.
>
> Alex
>
> [1] https://issues.apache.org/jira/browse/INFRA-19172
>
>
> >
> > Regards,
> > Gilles
> >
> > [1] https://sonarcloud.io/project/issues?id=commons-geometry
> > [2] https://lgtm.com/projects/g/apache/commons-geometry/?mode=list
> >
> > > I could try to get an RC out this weekend.
> > >
> > > Regards,
> > > Matt J
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >

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

Re: [Math] Issue in POM (?)

[Matt Juntunen]

Even though I've included the example module binaries in releases for
commons-numbers and commons-geometry, I would vote that we only
include them in source form in the future. For these particular
projects, they do not seem to be worthwhile to have as binaries. I
have not looked at the commons-math examples, though.

-Matt J

On Tue, Jul 20, 2021 at 7:17 PM Gilles Sadowski  wrote:
>
> Le mer. 21 juil. 2021 à 00:32, Matt Juntunen
>  a écrit :
> >
> > > I completely agree.  But how can we release (some official version of)
> > > the project as source without also releasing the (convenience) binaries
> > > for everything?
> >
> > I don't understand the question here. Wouldn't we just include all
> > example code in the source distribution but only create binaries for
> > the primary API? Is there some requirement related to what binaries
> > are produced?
>
> In practice, all sources are handled in the same way and the
> question has to be raised so that an answer can be given...
>
> >
> > -Matt J
> >
> > On Sun, Jul 18, 2021 at 5:14 PM Gilles Sadowski  
> > wrote:
> > >
> > > > > > > [...]
> > > > > > Building from the project root I get the same error you reported.
> > > > > >
> > > > > > This post of StackOverflow [1] indicates that this is a problem with
> > > > > > running the shade plugin within a multi-phase command. It is 
> > > > > > related to
> > > > > > dependency resolution when the shade plugin tried to incorporate 
> > > > > > all the
> > > > > > classes in the final jar. If building all the classes it the same 
> > > > > > phase
> > > > > > then it appears to break. If left to download them (as in my first
> > > > > example)
> > > > > > then it works.
> > > > >
> > > > > $ mvn verify
> > > > > --> SUCCESS
> > > > >
> > > > > $ mvn verify site
> > > > > --> SUCCESS
> > > > >
> > > > > $ mvn verify test site
> > > > > --> FAILURE
> > > > >
> > > > > $ mvn test package verify site
> > > > > --> SUCCESS
> > > > >
> > > >
> > > > This is inconsistent to say the least. The bug MSHADE-215 [1] appears to
> > > > indicate that running 'test package' will fail and running 'package' 
> > > > will
> > > > succeed. Anyway it may be the same thing where adding the 'test' target
> > > > somewhere in the set of targets causes the shade plugin to include 
> > > > classes
> > > > using a directory but label them as a jar.
> > > >
> > > >
> > > > [1] https://issues.apache.org/jira/browse/MSHADE-215
> > > >
> > > >
> > > > >
> > > > > I notice that junit runs in the "verify" phase; so, is the "test" 
> > > > > phase
> > > > > always redundant (before a commit)?
> > > > >
> > > >
> > > > If running a target that is after 'test' in the lifecycle then yes, 
> > > > 'test'
> > > > is redundant. If you use 'verify' you do not need 'test'. Adding 'test'
> > > > appears to trigger a bug in the shade plugin using some combinations of
> > > > targets later than 'test' from the default lifecycle.
> > > >
> > > >
> > > > >
> > > > > > I suggest the shaded jar is added within a profile and not on the 
> > > > > > default
> > > > > > build. Thus you need to explicitly build the shaded jar.
> > > > > >
> > > > > > Is it the intention to release this artifact? Otherwise build 
> > > > > > on-demand
> > > > > via
> > > > > > a profile should solve this.
> > > > >
> > > > > Do you propose that the "commons-math-examples" not be part of the
> > > > > official release?
> > > > >
> > > >
> > > > Are they of value as a dependency to be used by others? If we release 
> > > > the
> > > > standard jars from the examples modules then they can be included as a
> > > > dependency and that will bring everything upstream with it to a project.
> > > >
> > > > The question is whether the shaded jar has value as a released 
> > > > artifact. I
> > > > always considered them proof-of-application demos rather than programs 
> > > > that
> > > > had far reaching utility.
> > >
> > > I completely agree.  But how can we release (some official version of)
> > > the project as source without also releasing the (convenience) binaries
> > > for everything?
> > >
> > > Regards,
> > > Gilles
> > >
> > > > > >
> > > > > > [1] 
> > > > > > https://stackoverflow.com/questions/37942689/maven-shade-plugin-reports-error-creating-shaded-jar-target-classes-is-a-d
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [geometry] 1.0 release

[Matt Juntunen]

Geometry only uses rng for tests and performance benchmarks. Why do we
need to wait for the next release?

-Matt J

On Tue, Jul 20, 2021 at 12:56 PM Gilles Sadowski  wrote:
>
> Hi.
>
> Le mar. 20 juil. 2021 à 04:01, Matt Juntunen
>  a écrit :
> >
> > Hello,
> >
> > commons-numbers 1.0 has now been released so I'd like to release
> > commons-geometry 1.0 soon. I was going to include the following
> > modules:
> > - commons-geometry-core
> > - commons-geometry-euclidean
> > - commons-geometry-spherical
> > - commons-geometry-io-core
> > - commons-geometry-io-euclidean
> >
> > If there are no objections, I could try to get an RC out this weekend.
>
> I'd suggest that [RNG] (v1.4) be released first so that [Geometry]
> can depend on it.
>
> Also, there was an issue raised recently about what to do with the
> "examples" code.  Should it be part of the released artefacts?
>
> Best,
> Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [Math] Issue in POM (?)

[Matt Juntunen]

> I completely agree.  But how can we release (some official version of)
> the project as source without also releasing the (convenience) binaries
> for everything?

I don't understand the question here. Wouldn't we just include all
example code in the source distribution but only create binaries for
the primary API? Is there some requirement related to what binaries
are produced?

-Matt J

On Sun, Jul 18, 2021 at 5:14 PM Gilles Sadowski  wrote:
>
> > > > > [...]
> > > > Building from the project root I get the same error you reported.
> > > >
> > > > This post of StackOverflow [1] indicates that this is a problem with
> > > > running the shade plugin within a multi-phase command. It is related to
> > > > dependency resolution when the shade plugin tried to incorporate all the
> > > > classes in the final jar. If building all the classes it the same phase
> > > > then it appears to break. If left to download them (as in my first
> > > example)
> > > > then it works.
> > >
> > > $ mvn verify
> > > --> SUCCESS
> > >
> > > $ mvn verify site
> > > --> SUCCESS
> > >
> > > $ mvn verify test site
> > > --> FAILURE
> > >
> > > $ mvn test package verify site
> > > --> SUCCESS
> > >
> >
> > This is inconsistent to say the least. The bug MSHADE-215 [1] appears to
> > indicate that running 'test package' will fail and running 'package' will
> > succeed. Anyway it may be the same thing where adding the 'test' target
> > somewhere in the set of targets causes the shade plugin to include classes
> > using a directory but label them as a jar.
> >
> >
> > [1] https://issues.apache.org/jira/browse/MSHADE-215
> >
> >
> > >
> > > I notice that junit runs in the "verify" phase; so, is the "test" phase
> > > always redundant (before a commit)?
> > >
> >
> > If running a target that is after 'test' in the lifecycle then yes, 'test'
> > is redundant. If you use 'verify' you do not need 'test'. Adding 'test'
> > appears to trigger a bug in the shade plugin using some combinations of
> > targets later than 'test' from the default lifecycle.
> >
> >
> > >
> > > > I suggest the shaded jar is added within a profile and not on the 
> > > > default
> > > > build. Thus you need to explicitly build the shaded jar.
> > > >
> > > > Is it the intention to release this artifact? Otherwise build on-demand
> > > via
> > > > a profile should solve this.
> > >
> > > Do you propose that the "commons-math-examples" not be part of the
> > > official release?
> > >
> >
> > Are they of value as a dependency to be used by others? If we release the
> > standard jars from the examples modules then they can be included as a
> > dependency and that will bring everything upstream with it to a project.
> >
> > The question is whether the shaded jar has value as a released artifact. I
> > always considered them proof-of-application demos rather than programs that
> > had far reaching utility.
>
> I completely agree.  But how can we release (some official version of)
> the project as source without also releasing the (convenience) binaries
> for everything?
>
> Regards,
> Gilles
>
> > > >
> > > > [1] 
> > > > https://stackoverflow.com/questions/37942689/maven-shade-plugin-reports-error-creating-shaded-jar-target-classes-is-a-d
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

[geometry] 1.0 release

[Matt Juntunen]

Hello,

commons-numbers 1.0 has now been released so I'd like to release
commons-geometry 1.0 soon. I was going to include the following
modules:
- commons-geometry-core
- commons-geometry-euclidean
- commons-geometry-spherical
- commons-geometry-io-core
- commons-geometry-io-euclidean

If there are no objections, I could try to get an RC out this weekend.

Regards,
Matt J

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

[ANNOUNCEMENT] Apache Commons Numbers Version 1.0 Released

[Matt Juntunen]

The Apache Commons Team is pleased to announce the availability of
version 1.0 of "Apache Commons Numbers".

Apache Commons Numbers provides number types and utilities.

Changes in this version include:

Fixed Bugs:
o NUMBERS-153:  Use iterative implementation of "trigamma" function. Thanks
to
Dmitriy Golovashkin for reporting. Thanks to Gilles Sadowski.
o NUMBERS-150:  "Fraction/BigFraction": Fixed pow(int) to handle
Integer.MIN_VALUE and throw ArithmeticException for negative exponents
to a
fraction of zero. Thanks to Jin Xu.
o NUMBERS-147:  Fixed Fraction/BigFraction from(double, int) to support
Integer.MIN_VALUE as max denominator. Thanks to Alex Herbert.

Changes:
o NUMBERS-163:  Combined "LinearCombination" and "Summation" into single
"Sum"
class. Thanks to Matt Juntunen.
o NUMBERS-164:  Added SortInPlace utility, original from Commons Math.
Thanks
to Gilles Sadowski.
o NUMBERS-159:  Moved "Norms", "LinearCombination", and "Summation" from
commons-numbers-arrays module to commons-numbers-core module. Moved
"CosAngle" from commons-numbers-arrays module to commons-numbers-angle
module. Thanks to Matt Juntunen.
o NUMBERS-156:  Replaced "SafeNorm" with "Norms". Added "Summation" class
for
extended precision summation. Thanks to Matt Juntunen.
o NUMBERS-161:  "Angle" replaces "PlaneAngle" and "PlaneAngleRadians".
Thanks
to Gilles Sadowski.
o NUMBERS-158:  Replace angle normalize method with normalizer method that
returns operator instance. Thanks to Gilles Sadowski.
o NUMBERS-157:  Adding Reduce operation originally from Commons Math to
commons-numbers-angle module. Thanks to Gilles Sadowski.
o NUMBERS-142:  "LinearCombination": Update to use the dot2s algorithm.
Avoids
construction of an intermediate array for array dot products. Update the
hi-lo splitting algorithm to use Dekker's split to ensure the product
round-off is computed to exact precision. Thanks to Alex Herbert.
o NUMBERS-154:  Precision compareTo method now handles NaN properly to
ensure
consistent sorting. Thanks to Gilles Sadowski.
o NUMBERS-149:  "Fraction": Port tests from commons-lang Fraction to
demonstrate functional compatibility between the lang and numbers
implementation of Fraction. Thanks to Jin Xu.
o NUMBERS-151:  "ArithmeticUtils": Refine pow(int, int) and pow(long, int)
for
edge cases. Thanks to Jin Xu.


Historical list of changes:
  https://commons.apache.org/proper/commons-numbers/changes-report.html

For complete information on Apache Commons Number, including instructions
on how
to submit bug reports, patches, or suggestions for improvement, see the
Apache Commons Numbers website:
  https://commons.apache.org/proper/commons-numbers/

Distribution packages can be downloaded from
  http://commons.apache.org/proper/commons-numbers/download_numbers.cgi


Regards,
Matt Juntunen, on behalf of the Apache Commons Team