[jira] [Commented] (GEOMETRY-110) 3D Convex Hull

[Matt Juntunen (Jira)]

[ 
https://issues.apache.org/jira/browse/GEOMETRY-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841554#comment-17841554
 ] 

Matt Juntunen commented on GEOMETRY-110:


[~agoss], I've merged the implementation you provided in [PR 
#255|https://github.com/apache/commons-geometry/pull/225]. Thank you for your 
work on this!

> 3D Convex Hull
> --
>
> Key: GEOMETRY-110
> URL: https://issues.apache.org/jira/browse/GEOMETRY-110
> Project: Commons Geometry
>  Issue Type: New Feature
>    Reporter: Matt Juntunen
>Assignee: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> We currently only have a 2D convex hull generator implementation. We should 
> add a 3D convex hull implementation, perhaps based on the 
> [Quickhull|https://en.wikipedia.org/wiki/Quickhull] algorithm.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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
>
>

[jira] [Commented] (GEOMETRY-110) 3D Convex Hull

[Matt Juntunen (Jira)]

[ 
https://issues.apache.org/jira/browse/GEOMETRY-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782582#comment-17782582
 ] 

Matt Juntunen commented on GEOMETRY-110:


Awesome! Thanks, [~agoss]! I'll plan on taking a look this weekend.

> 3D Convex Hull
> --
>
> Key: GEOMETRY-110
> URL: https://issues.apache.org/jira/browse/GEOMETRY-110
> Project: Commons Geometry
>  Issue Type: New Feature
>    Reporter: Matt Juntunen
>Assignee: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> We currently only have a 2D convex hull generator implementation. We should 
> add a 3D convex hull implementation, perhaps based on the 
> [Quickhull|https://en.wikipedia.org/wiki/Quickhull] algorithm.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (GEOMETRY-155) Implement getMidpoint(Vector x)

[Matt Juntunen (Jira)]

[ 
https://issues.apache.org/jira/browse/GEOMETRY-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743605#comment-17743605
 ] 

Matt Juntunen commented on GEOMETRY-155:


This can be done by multiplying the vector by 0.5. There is no need for a 
separate method for this.
{code:java}
Vector3D v = ...
Vector3D midPoint = v.multiply(0.5);
{code}

> Implement getMidpoint(Vector x)
> ---
>
> Key: GEOMETRY-155
> URL: https://issues.apache.org/jira/browse/GEOMETRY-155
> Project: Commons Geometry
>  Issue Type: New Feature
>  Components: euclidean1D, euclidean2D, euclidean3D
>Reporter: Dimitrios Efthymiou
>Priority: Minor
>  Labels: features
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> It takes a vector and returns the point that is in the middle of the vector



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (GEOMETRY-150) implement isCodirectionalTo(Vector y)

[Matt Juntunen (Jira)]

[ 
https://issues.apache.org/jira/browse/GEOMETRY-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743601#comment-17743601
 ] 

Matt Juntunen commented on GEOMETRY-150:


I believe this method is general enough and useful enough to warrant adding it. 
Since we must maintain backwards compatibility with 1.0 for 1.1, we need to add 
it as a default method to the interface, which (as mentioned before) we can do. 
It may be that we can override the default implementation in some cases for 
better performance. I'm not sure on that yet.

> implement isCodirectionalTo(Vector y)
> -
>
> Key: GEOMETRY-150
> URL: https://issues.apache.org/jira/browse/GEOMETRY-150
> Project: Commons Geometry
>  Issue Type: New Feature
>  Components: euclidean1D
>Reporter: Dimitrios Efthymiou
>Priority: Minor
>  Labels: features
> Fix For: 1.1
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> implement isCodirectionalTo(Vector y) method in the Vector interface. The 
> isCodirectionalTo() checks if the 2 vectors point at the same direction. This 
> means that each vector can be obtained from the other by multiplying by a 
> positive scalar.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (GEOMETRY-154) Implement divideVectorWithRatio(Vector x, double ratio)

[Matt Juntunen (Jira)]

[ 
https://issues.apache.org/jira/browse/GEOMETRY-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743597#comment-17743597
 ] 

Matt Juntunen commented on GEOMETRY-154:


[~dimitrios.efthymiou], I'm not sold on the idea of adding this method based on 
these use cases. For the graphics use case, there is already the 
{{EuclideanVector.lerp}} method, which linearly interpolates between two 
vectors. For the other use cases, one can compute the desired length ratios and 
then use scalar multiplication to get the desired vectors. The computation of 
the length ratios will depend on what the caller is trying to do and so should 
not be part of this library, IMHO.

Ex:
{code:java}
// point between other points
Vector3D a = Vector3D.of(1, 2, 3);
Vector3D b = Vector3D.of(4, 5, 6);

Vector3D midPoint = a.lerp(b, 0.5);

// split the vector into two parts; in this case, we'll just do a simple 1/4, 
3/4 split
Vector3D oneQuarter = a.multiply(0.25);
Vector3D threeQuarters = a.multiply(0.75);
{code}

> Implement divideVectorWithRatio(Vector x, double ratio)
> ---
>
> Key: GEOMETRY-154
> URL: https://issues.apache.org/jira/browse/GEOMETRY-154
> Project: Commons Geometry
>  Issue Type: New Feature
>  Components: euclidean1D, euclidean2D, euclidean3D
>Reporter: Dimitrios Efthymiou
>Priority: Minor
>  Labels: features
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> It takes a vector, say, u = (10) and divides it with ratio, say 1/2. That 
> will return a pair of vectors v = (3.33) and w = (6.66). Regardless of 
> dimensions, both vectors start at the point of origin



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (GEOMETRY-154) Implement divideVectorWithRatio(Vector x, double ratio)

[Matt Juntunen (Jira)]

[ 
https://issues.apache.org/jira/browse/GEOMETRY-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743573#comment-17743573
 ] 

Matt Juntunen commented on GEOMETRY-154:


What would be a use case for this method? I'm not seeing one right off the bat.

> Implement divideVectorWithRatio(Vector x, double ratio)
> ---
>
> Key: GEOMETRY-154
> URL: https://issues.apache.org/jira/browse/GEOMETRY-154
> Project: Commons Geometry
>  Issue Type: New Feature
>  Components: euclidean1D, euclidean2D, euclidean3D
>Reporter: Dimitrios Efthymiou
>Priority: Minor
>  Labels: features
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> It takes a vector, say, u = (10) and divides it with ratio, say 1/2. That 
> will return a pair of vectors v = (3.33) and w = (6.66). Regardless of 
> dimensions, both vectors start at the point of origin



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (GEOMETRY-150) implement isCodirectionalTo(Vector y)

[Matt Juntunen (Jira)]

[ 
https://issues.apache.org/jira/browse/GEOMETRY-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743185#comment-17743185
 ] 

Matt Juntunen commented on GEOMETRY-150:


A few comments:
- {{Vectors}} is in the {{internal}} package and is not intended to be part of 
the public API. We should not add any method intended for public use there.
- Two vectors are codirectional if the dot product of their normalized forms is 
equal to 1. But how close to 1 do we have to be in order to return true? This 
makes me think that this method needs to accept a 
{{Precision.DoubleEquivalence}} in order to allow the caller to specify how 
close we need to be.
- This could possibly be implemented as a default method in {{Vector}} with 
something like this:
{code:java}
default boolean isCodirectionalWith(final V other, final 
Precision.DoubleEquivalence precision) {
final V thisNormalized = normalizeOrNull();
final V otherNormalized = other.normalizeOrNull();

if (thisNormalized != null && otherNormalized != null) {
final double dot = thisNormalized.dot(otherNormalized);
return precision.eq(dot, 1.0);
}
return false;
}
{code}

> implement isCodirectionalTo(Vector y)
> -
>
> Key: GEOMETRY-150
> URL: https://issues.apache.org/jira/browse/GEOMETRY-150
> Project: Commons Geometry
>  Issue Type: New Feature
>  Components: euclidean1D
>Reporter: Dimitrios Efthymiou
>Priority: Minor
>  Labels: features
> Fix For: 1.1
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> implement isCodirectionalTo(Vector y) method in the Vector interface. The 
> isCodirectionalTo() checks if the 2 vectors point at the same direction. This 
> means that each vector can be obtained from the other by multiplying by a 
> positive scalar.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (GEOMETRY-144) Review API in "hull" module

[Matt Juntunen (Jira)]

[ 
https://issues.apache.org/jira/browse/GEOMETRY-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17690953#comment-17690953
 ] 

Matt Juntunen commented on GEOMETRY-144:


Sounds great! Thank you for your contributions on this!

> Review API in "hull" module
> ---
>
> Key: GEOMETRY-144
> URL: https://issues.apache.org/jira/browse/GEOMETRY-144
> Project: Commons Geometry
>  Issue Type: Task
>Reporter: Gilles Sadowski
>Assignee: Gilles Sadowski
>Priority: Minor
> Fix For: 1.1
>
>
> Review codes in the 
> [{{commons-geometry-hull}}|https://gitbox.apache.org/repos/asf?p=commons-geometry.git;a=tree;f=commons-geometry-hull;hb=HEAD]
>  module.
> (x) Minimize the public API



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (GEOMETRY-144) Review API in "hull" module

[Matt Juntunen (Jira)]

[ 
https://issues.apache.org/jira/browse/GEOMETRY-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17687515#comment-17687515
 ] 

Matt Juntunen commented on GEOMETRY-144:


bq.  i think that is a good proposition. At least in the three-dimensional case 
the Mesh seems to be more fitting than ConvexHull. What would we then do with 
two-dimensional algorithm is the end product LinePath?

Great! Yes, {{LinePath}} is what I was picturing for 2D.

bq. Having thought about it some more i believe we could go with the Builder 
pattern and make use of some heuristic like the Akl- Toussaint in the two 
dimensional case. I think one could continuously adjust the given quadrangle 
constructed and test all points previously added against it. Matt Juntunen you 
probably had something similar in mind. 

Yes, exactly. I'm picturing a simple test as points are added to skip points 
clearly not on the hull. After that, the full {{Quickhull}} algorithm would be 
run on what remains.

> Review API in "hull" module
> ---
>
> Key: GEOMETRY-144
> URL: https://issues.apache.org/jira/browse/GEOMETRY-144
> Project: Commons Geometry
>  Issue Type: Task
>Reporter: Gilles Sadowski
>Assignee: Gilles Sadowski
>Priority: Minor
> Fix For: 1.1
>
>
> Review codes in the 
> [{{commons-geometry-hull}}|https://gitbox.apache.org/repos/asf?p=commons-geometry.git;a=tree;f=commons-geometry-hull;hb=HEAD]
>  module.
> (x) Minimize the public API



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (GEOMETRY-144) Review API in "hull" module

[Matt Juntunen (Jira)]

[ 
https://issues.apache.org/jira/browse/GEOMETRY-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17684354#comment-17684354
 ] 

Matt Juntunen commented on GEOMETRY-144:


[~agoss], I've looked over your PR and it's looking good. I would like to see 
more unit tests, particularly in the areas of asserting the expected output 
vertices, checking that the algorithm is not sensitive to the order of the 
input points, and testing cases where input points are very close to each other 
wrt the configured precision. Before, we get there, though, I believe we first 
need to come to a consensus on the public API we want. Your suggestion of doing 
away with the {{ConvexHull3D}} interface and just using {{ConvexVolume}} got me 
thinking more about what is actually needed here. My primary use case for 
convex hull generation is during mesh manipulation. For example, you have a set 
of geometries in mesh form and you want to compute the convex hull of all of 
them together. This is a major reason I'm hesitant to use {{ConvexVolume}}: the 
mesh form of the hull is generated directly in the algorithm and if that is the 
desired end product, then converting to a {{ConvexVolume}} is just wasted work. 
What, then, do you think of using {{Mesh}} as the end product of convex hull 
operations? This would fulfill the requirement for easy access to vertex and 
face information as well as allowing hulls of zero size, as in the case where 
all points lie in the same plane. If needed, the caller can easily convert the 
{{Mesh}} instance into {{ConvexVolume}} or {{RegionBSPTree3D}}.

> Review API in "hull" module
> ---
>
> Key: GEOMETRY-144
> URL: https://issues.apache.org/jira/browse/GEOMETRY-144
> Project: Commons Geometry
>  Issue Type: Task
>Reporter: Gilles Sadowski
>Assignee: Gilles Sadowski
>Priority: Minor
> Fix For: 1.1
>
>
> Review codes in the 
> [{{commons-geometry-hull}}|https://gitbox.apache.org/repos/asf?p=commons-geometry.git;a=tree;f=commons-geometry-hull;hb=HEAD]
>  module.
> (x) Minimize the public API



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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
> >
> >
>

[jira] [Commented] (GEOMETRY-144) Review API in "hull" module

[Matt Juntunen (Jira)]

[ 
https://issues.apache.org/jira/browse/GEOMETRY-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17682847#comment-17682847
 ] 

Matt Juntunen commented on GEOMETRY-144:


I still believe we should just go with one algorithm and hide all of the 
details of the computation. The majority of users will not have any preference 
as to which algorithm is used as long as the implementation is accurate and 
fast.

{quote}Is there really a need for a {{ConvexHull}} interface as there is right 
now in the hull module? As I see it, the interface offers little additional 
functionality compared to the {{ConvexArea}} and {{ConvexVolume}} class (keeps 
only track of the vertices in three dimensions). 
{quote}

I do see utility in having the additional interface, even though it is similar 
to {{ConvexVolume}}. The main reasons are
1. it provides direct access to the vertices on the hull, and
2. it supports hulls of zero size, i.e., with all points lying entirely on a 
single plane, line, or point.

{{ConvexVolume}} does provide access to vertices but only by iterating through 
each face. If you wanted to filter a cloud of points to only those points on 
the convex hull using {{ConvexVolume}}, you would have to construct the hull 
and then iterate through each face, collecting the vertices and removing 
duplicates. This seems unnecessary since the list of used vertices is directly 
available from the hull generation. Also, a convex hull does not need to have a 
3 dimensional size, which is a requirement of {{ConvexVolume}}. Attempting to 
construct a {{ConvexVolume}} of zero size results in an exception.

> Review API in "hull" module
> ---
>
> Key: GEOMETRY-144
> URL: https://issues.apache.org/jira/browse/GEOMETRY-144
> Project: Commons Geometry
>  Issue Type: Task
>Reporter: Gilles Sadowski
>Assignee: Gilles Sadowski
>Priority: Minor
> Fix For: 1.1
>
>
> Review codes in the 
> [{{commons-geometry-hull}}|https://gitbox.apache.org/repos/asf?p=commons-geometry.git;a=tree;f=commons-geometry-hull;hb=HEAD]
>  module.
> (x) Minimize the public API



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Re: [geometry] How to get the intersection face from two overlaping ConvexPolygon3D instances?

[Matt Juntunen]

Hello,

> I'm working on a wood working design and manufacturing software based on 
> Trimble Sketchup.
> What i'm planning currently, is trying to move some board connecting 
> detection from Sketchup
> plugin side ( based on some Sketchup 3D api in ruby ) to server side (in 
> java, of course). Commons
> Geometry is the best 3D lib i can find in java world.

Glad to hear it! Feel free to report any bugs you find or features you
feel would be useful on JIRA [1]. Good luck on your project!

Regards,
Matt J

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

On Sat, Sep 17, 2022 at 10:57 PM Bai Song  wrote:
>
> Hi,
>
>
>   Alex, thanks for your reply, saved me a lot of time!
>
>
>   Matt, thanks for your detailed demo of 3D pop down to 2D, this helps me a 
> lot! I'll do more trial in
>
> this way.
>
>
>
>   I'm working on a wood working design and manufacturing software based on 
> Trimble Sketchup.
>
> What i'm planning currently, is trying to move some board connecting 
> detection from Sketchup
>
> plugin side ( based on some Sketchup 3D api in ruby ) to server side (in 
> java, of course). Commons
>
> Geometry is the best 3D lib i can find in java world.
>
>
>
>   Thanks again for your work!
>
>
> Regards,
> Bai Song
>
> At 2022-09-17 10:58:33, "Matt Juntunen"  wrote:
> >Hello,
> >
> >Alex is correct in that the intersection operation you are attempting
> >to perform will only work in 2D. When you constructed bsp1 and bsp2
> >from the faces, what you ended up with was 2 half spaces of infinite
> >size.
> >
> >List list1 = new ArrayList<>();
> >list1.add(face1);
> >RegionBSPTree3D bsp1 = RegionBSPTree3D.from(list1); // this is
> >an infinite half space
> >
> >List list2 = new ArrayList<>();
> >list2.add(face2);
> >RegionBSPTree3D bsp2 = RegionBSPTree3D.from(list2); // this is
> >also an infinite half-space and is actually identical to the first one
> >
> >(The reason for this has to do with the way BSP trees represent
> >regions. I suggest taking a look at the BSP tree tutorial on the
> >commons-geometry site [1].)
> >
> >The intersection of those two infinite half-spaces is itself an
> >infinite half-space. Regions of infinite size do not have a defined
> >centroid, which is why the centroid in your example is null.
> >
> >In order to compute the intersection of the two polygons in your
> >example, we have to use 2D space. We can either do the entire thing in
> >2D (as Alex demonstrated), or we can start in 3D and pop down to 2D
> >when needed. This is the approach that I will show here. We'll start
> >with the same 3D convex polygons that you had:
> >
> >List pts1 = Arrays.asList(
> >Vector3D.of(0, 10, 0),
> >Vector3D.of(30, 10, 0),
> >Vector3D.of(30, 20, 0),
> >Vector3D.of(0, 20, 0));
> >ConvexPolygon3D face1 = Planes.convexPolygonFromVertices(pts1,
> >precision);
> >
> >List pts2 = Arrays.asList(
> >Vector3D.of(10, 0, 0),
> >Vector3D.of(20, 0, 0),
> >Vector3D.of(20, 30, 0),
> >Vector3D.of(10, 30, 0));
> >ConvexPolygon3D face2 = Planes.convexPolygonFromVertices(pts2,
> >precision);
> >
> >Now, in order to perform the 2D intersection, we will first access the
> >2D geometries that are embedded in the 3D planes of the
> >ConvexPolygon3D instances. You can picture a ConvexPolygon3D (and any
> >other PlaneSubset subclass) as a 2D sticker stuck to a pane of glass
> >(the infinite 3D plane). In the lines below, we are extracting the 2D
> >"sticker" in order to work with it directly.
> >
> >ConvexArea area1 = face1.getEmbedded().getSubspaceRegion();
> >ConvexArea area2 = face2.getEmbedded().getSubspaceRegion();
> >
> >We can now compute the intersection in 2D:
> >
> >RegionBSPTree2D areaBsp = RegionBSPTree2D.empty();
> >areaBsp.intersection(area1.toTree(), area2.toTree());
> >
> >This gives us a finite 2D region with the expected centroid:
> >
> >Vector2D centroid2d = areaBsp.getCentroid();
> >System.out.println(centroid2d); // prints (15.002,
> >-15.002)
> >
> >If we wish to take this 2D centroid back up to 3D, we can again use
> >the subspace embedding information from the faces. In this case, we
> >only need to use one of the faces:
> >
> >

Re: [geometry] How to get the intersection face from two overlaping ConvexPolygon3D instances?

[Matt Juntunen]

Hello,

Alex is correct in that the intersection operation you are attempting
to perform will only work in 2D. When you constructed bsp1 and bsp2
from the faces, what you ended up with was 2 half spaces of infinite
size.

List list1 = new ArrayList<>();
list1.add(face1);
RegionBSPTree3D bsp1 = RegionBSPTree3D.from(list1); // this is
an infinite half space

List list2 = new ArrayList<>();
list2.add(face2);
RegionBSPTree3D bsp2 = RegionBSPTree3D.from(list2); // this is
also an infinite half-space and is actually identical to the first one

(The reason for this has to do with the way BSP trees represent
regions. I suggest taking a look at the BSP tree tutorial on the
commons-geometry site [1].)

The intersection of those two infinite half-spaces is itself an
infinite half-space. Regions of infinite size do not have a defined
centroid, which is why the centroid in your example is null.

In order to compute the intersection of the two polygons in your
example, we have to use 2D space. We can either do the entire thing in
2D (as Alex demonstrated), or we can start in 3D and pop down to 2D
when needed. This is the approach that I will show here. We'll start
with the same 3D convex polygons that you had:

List pts1 = Arrays.asList(
Vector3D.of(0, 10, 0),
Vector3D.of(30, 10, 0),
Vector3D.of(30, 20, 0),
Vector3D.of(0, 20, 0));
ConvexPolygon3D face1 = Planes.convexPolygonFromVertices(pts1,
precision);

List pts2 = Arrays.asList(
Vector3D.of(10, 0, 0),
Vector3D.of(20, 0, 0),
Vector3D.of(20, 30, 0),
Vector3D.of(10, 30, 0));
ConvexPolygon3D face2 = Planes.convexPolygonFromVertices(pts2,
precision);

Now, in order to perform the 2D intersection, we will first access the
2D geometries that are embedded in the 3D planes of the
ConvexPolygon3D instances. You can picture a ConvexPolygon3D (and any
other PlaneSubset subclass) as a 2D sticker stuck to a pane of glass
(the infinite 3D plane). In the lines below, we are extracting the 2D
"sticker" in order to work with it directly.

ConvexArea area1 = face1.getEmbedded().getSubspaceRegion();
ConvexArea area2 = face2.getEmbedded().getSubspaceRegion();

We can now compute the intersection in 2D:

RegionBSPTree2D areaBsp = RegionBSPTree2D.empty();
areaBsp.intersection(area1.toTree(), area2.toTree());

This gives us a finite 2D region with the expected centroid:

Vector2D centroid2d = areaBsp.getCentroid();
System.out.println(centroid2d); // prints (15.002,
-15.002)

If we wish to take this 2D centroid back up to 3D, we can again use
the subspace embedding information from the faces. In this case, we
only need to use one of the faces:

Vector3D centroid3d = face1.getEmbedded().toSpace(centroid2d);
System.out.println(centroid3d); // prints (15.002,
15.002, 0.0)

I hope this helps. Thank you for your interest in this project and
feel free to reach out if you have any more questions.

Regards,
Matt J

[1] https://commons.apache.org/proper/commons-geometry/tutorials/bsp-tree.html

On Fri, Sep 16, 2022 at 6:10 AM Alex Herbert  wrote:
>
> This may be related to the fact that you are using the 3D API with 2D
> areas. Since the shapes have no volume the intersection may not be defined.
>
> This does work as expected in 2D:
>
> Precision.DoubleEquivalence precision =
> Precision.doubleEquivalenceOfEpsilon(1e-6);
>
> List pts1 = new ArrayList<>();
> pts1.add(Vector2D.of(0, 10));
> pts1.add(Vector2D.of(30, 10));
> pts1.add(Vector2D.of(30, 20));
> pts1.add(Vector2D.of(0, 20));
> ConvexArea face1 = ConvexArea.convexPolygonFromVertices(pts1,
> precision);
>
> List pts2 = new ArrayList<>();
> pts2.add(Vector2D.of(10, 0));
> pts2.add(Vector2D.of(20, 0));
> pts2.add(Vector2D.of(20, 30));
> pts2.add(Vector2D.of(10, 30));
> ConvexArea face2 = ConvexArea.convexPolygonFromVertices(pts2,
> precision);
>
> RegionBSPTree2D bsp1 = RegionBSPTree2D.from(face1.getBoundaries());
>
> RegionBSPTree2D bsp2 = RegionBSPTree2D.from(face2.getBoundaries());
>
> RegionBSPTree2D result = RegionBSPTree2D.empty();
> result.intersection(bsp1, bsp2);
>
> System.out.println("Hello, Geometry! Centroid: " +
> result.getCentroid());
>
> Result:
>
> Hello, Geometry! Centroid: (15.002, 15.002)
>
> There may be a setting for the 3D equivalent to allow intersections on the
> plane to be returned. I could not find anything obvious in the API.
>
> Regards,
>
> Alex
>
>
>
> On Fri, 16 Sept 2022 at 10:03, Bai Song  wrote:
>
> > Hi, Geometry Team
> >
> > I'm learning this interesting project and facing some difficulties when i
> > did a little 

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: SBOM Generation

[Matt Juntunen]

Hello all,

Continuing the conversation here...

Gary, I wouldn't say that an SBOM is an XML transformation of a POM.
CycloneDX, for example, can contain information not in a POM, such as
license information, service relationships, and vulnerabilities [1].
The component identifiers used are also different in that they
describe the component uniquely across the entire software space
(different languages, packaging schemes, etc.) and not just in the
Maven ecosystem. However, for the purposes of Apache Commons, I expect
that there will be a good amount of overlap between the information in
the POM and that in the SBOM.

Mark, can you provide an more details on how we should interact with
OpenSSF? Do we simply show up in the Zoom meeting or is there some
sort of protocol we need to follow? Are you picturing us following
their lead on SBOM recommendations?

Regards,
Matt J

[1] https://cyclonedx.org/specification/overview/

On Thu, Jul 21, 2022 at 12:51 PM David Nalley  wrote:
>
> I hesitate to weigh in because I am not going to be doing any of the work,
> but I think it's useful to consider what you're trying to accomplish with
> SBOM. I used to spend a lot of time in the SBOM space.
>
> If it's license compliance, SPDX makes a lot of sense. It was built from
> the ground up to be a license compliance data exchange format.
> Folks are aggressively working on SPDX 3.0 and adding some uses cases
> around security and to address some of the gaps that SBOM advocates have
> called out.
>
> CycloneDX was built from the ground up as a SBOM and security tool. What's
> really telling for me is that there are already a lot of tools for sharing,
> querying, and managing BoMs in the CycloneDX format. Just generating the
> BoM may be all that we do, but for it to be useful to our users they need
> tools that can ingest, and do something with the BoM. That's improving by
> the day with SPDX, but great tooling exists already for CycloneDX.
>
> --David
>
>
>
> On Mon, Jul 18, 2022 at 8:18 AM Steve Springett
>  wrote:
>
> > There may be value in supporting both formats. Most security vendors
> > support the CycloneDX standard since its from OWASP and was purpose-built
> > for security use cases. Some security vendors support SPDX as well. OpenSSF
> > has publicly stated that they will only support SPDX due to both OpenSSF
> > and SPDX being Linux Foundation projects. Unfortunately, this view is
> > contrary to the adoption we’re seeing in the global security community.
> >
> > Sonatype, the stewards of Maven Central, have been a big supporter of
> > CycloneDX since 2019 and have recommitted to favoring it going forward.
> >
> > https://www.sonatype.com/press-releases/sonatype-embraces-cyclonedx-standard-for-integrating-software-bills-of-materials-sboms
> >
> > Regardless, the end goal is to have authoritative SBOMs published to Maven
> > Central similar to what DropWizard is doing.
> >
> > https://repo1.maven.org/maven2/io/dropwizard/dropwizard-core/2.1.1/
> >
> > Non-authorative SBOMs may be on the roadmap for Maven Central.
> >
> >
> > —Steve
> >
> >
> > On 2022/07/17 16:11:28 Matt Juntunen wrote:
> > > Hello,
> > >
> > > The Apache Commons project recently received a PR [1] for our parent
> > > POM that includes the generation of software bill of materials (SBOM)
> > > artifacts during the build. During the following discussion [2] on our
> > > dev mailing list, it was suggested that this mailing list would be the
> > > appropriate place to discuss this topic. In short, we are trying to
> > > answer the following questions:
> > >
> > > 1. Should our projects include SBOM artifacts?
> > > 2. If so, what format should we use (e.g., SPDX [3] or CycloneDX [4])?
> > >
> > > I am of the opinion that the ASF in general (and Apache Commons in
> > > particular) should provide these artifacts when appropriate as they 1)
> > > are useful when performing vulnerability and software supply chain
> > > analysis and 2) promote good cybersecurity practices in the community.
> > >
> > > What guidance does the ASF provide on this issue? What, if any,
> > > standards have been adopted?
> > >
> > > Regards,
> > > Matt J
> > >
> > > [1] https://github.com/apache/commons-parent/pull/122
> > > [2] https://lists.apache.org/thread/kvdz39t5wndojbtqqn84smm51rt89fnx
> > > [3] https://spdx.dev/
> > > [4] https://cyclonedx.org/
> > >
> > > -
> > > To unsubscribe, e-mail:
> > security-discuss-

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

SBOM Generation

[Matt Juntunen]

Hello,

The Apache Commons project recently received a PR [1] for our parent
POM that includes the generation of software bill of materials (SBOM)
artifacts during the build. During the following discussion [2] on our
dev mailing list, it was suggested that this mailing list would be the
appropriate place to discuss this topic. In short, we are trying to
answer the following questions:

1. Should our projects include SBOM artifacts?
2. If so, what format should we use (e.g., SPDX [3] or CycloneDX [4])?

I am of the opinion that the ASF in general (and Apache Commons in
particular) should provide these artifacts when appropriate as they 1)
are useful when performing vulnerability and software supply chain
analysis and 2) promote good cybersecurity practices in the community.

What guidance does the ASF provide on this issue? What, if any,
standards have been adopted?

Regards,
Matt J

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

-
To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org
For additional commands, e-mail: security-discuss-h...@community.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

[jira] [Resolved] (CONFIGURATION-817) Upgrade to JUnit 5

[Matt Juntunen (Jira)]

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

Matt Juntunen resolved CONFIGURATION-817.
-
Resolution: Done

> Upgrade to JUnit 5
> --
>
> Key: CONFIGURATION-817
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-817
> Project: Commons Configuration
>  Issue Type: Task
>  Components: Build
>Reporter: Rob Spoor
>Priority: Minor
>
> From https://lists.apache.org/thread/ygtkpch0s7nss4vx8xfytwsbnv7mzss9
> {quote}Matt Juntunen - Monday, 4 July 2022 04:40:43 CEST
> Re: [VOTE] Release Apache Commons Configuration 2.8.0 based on RC3
> 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{quote}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CONFIGURATION-817) Upgrade to JUnit 5

[Matt Juntunen (Jira)]

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17567643#comment-17567643
 ] 

Matt Juntunen commented on CONFIGURATION-817:
-

Done in commits
- 0809670def4fee8c89fb9110fa5c8e3e0e357c95
- 36ad0945b1f86d04c38fd00582ee3c71759aa16a
- 24901b37011083797d6f946a95f14e9dd09ef1c6
- e5029984051e1d4dac51347bfcb293bd3badfeac

Thanks, [~Spoor]!


> Upgrade to JUnit 5
> --
>
> Key: CONFIGURATION-817
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-817
> Project: Commons Configuration
>  Issue Type: Task
>  Components: Build
>Reporter: Rob Spoor
>Priority: Minor
>
> From https://lists.apache.org/thread/ygtkpch0s7nss4vx8xfytwsbnv7mzss9
> {quote}Matt Juntunen - Monday, 4 July 2022 04:40:43 CEST
> Re: [VOTE] Release Apache Commons Configuration 2.8.0 based on RC3
> 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{quote}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Comment Edited] (CONFIGURATION-817) Upgrade to JUnit 5

[Matt Juntunen (Jira)]

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17565221#comment-17565221
 ] 

Matt Juntunen edited comment on CONFIGURATION-817 at 7/12/22 2:17 AM:
--

bq. How do we feel about using some more advanced JUnit 5 functionality? 

IMHO, the examples given do not add to the readability of the tests so my vote 
is to leave them as-is. 

bq. Is it perhaps an idea to split this ticket into two?

Sounds perfectly reasonable to me. Plus, as you mention, others will be able to 
use JUnit 5 sooner rather than later.


was (Author: mattjuntunen):
> How do we feel about using some more advanced JUnit 5 functionality? 

IMHO, the examples given do not add to the readability of the tests so my vote 
is to leave them as-is. 

> Is it perhaps an idea to split this ticket into two?

Sounds perfectly reasonable to me. Plus, as you mention, others will be able to 
use JUnit 5 sooner rather than later.

> Upgrade to JUnit 5
> --
>
> Key: CONFIGURATION-817
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-817
> Project: Commons Configuration
>  Issue Type: Task
>  Components: Build
>Reporter: Rob Spoor
>Priority: Minor
>
> From https://lists.apache.org/thread/ygtkpch0s7nss4vx8xfytwsbnv7mzss9
> {quote}Matt Juntunen - Monday, 4 July 2022 04:40:43 CEST
> Re: [VOTE] Release Apache Commons Configuration 2.8.0 based on RC3
> 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{quote}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CONFIGURATION-817) Upgrade to JUnit 5

[Matt Juntunen (Jira)]

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17565221#comment-17565221
 ] 

Matt Juntunen commented on CONFIGURATION-817:
-

> How do we feel about using some more advanced JUnit 5 functionality? 

IMHO, the examples given do not add to the readability of the tests so my vote 
is to leave them as-is. 

> Is it perhaps an idea to split this ticket into two?

Sounds perfectly reasonable to me. Plus, as you mention, others will be able to 
use JUnit 5 sooner rather than later.

> Upgrade to JUnit 5
> --
>
> Key: CONFIGURATION-817
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-817
> Project: Commons Configuration
>  Issue Type: Task
>  Components: Build
>Reporter: Rob Spoor
>Priority: Minor
>
> From https://lists.apache.org/thread/ygtkpch0s7nss4vx8xfytwsbnv7mzss9
> {quote}Matt Juntunen - Monday, 4 July 2022 04:40:43 CEST
> Re: [VOTE] Release Apache Commons Configuration 2.8.0 based on RC3
> 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{quote}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (CONFIGURATION-817) Upgrade to JUnit 5

[Matt Juntunen (Jira)]

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17564768#comment-17564768
 ] 

Matt Juntunen commented on CONFIGURATION-817:
-

Wow! I just wished for something out loud on the mailing list and it magically 
happened! Thanks, [~Spoor]!

One thing I was picturing during the upgrade was to remove all of the 
unnecessary assertion messages. For example, {{ConfigurationAssert}} line 94 
contains the line
{code:java}
assertEquals(expEquals, o1.equals(o2), "Wrong result of equals()");
{code}
The custom assertion message in this case feels like extra noise since the 
failure could be traced back to this line in the test anyway, and would most 
likely need to be in order to fix the issue. What do you think of removing 
these superfluous messages? I think a good starting rule of thumb would be to 
remove any message that doesn't include a value from the actual test.

> Upgrade to JUnit 5
> --
>
> Key: CONFIGURATION-817
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-817
> Project: Commons Configuration
>  Issue Type: Task
>  Components: Build
>Reporter: Rob Spoor
>Priority: Minor
>
> From https://lists.apache.org/thread/ygtkpch0s7nss4vx8xfytwsbnv7mzss9
> {quote}Matt Juntunen - Monday, 4 July 2022 04:40:43 CEST
> Re: [VOTE] Release Apache Commons Configuration 2.8.0 based on RC3
> 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{quote}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

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

[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: [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

[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

[jira] [Closed] (CONFIGURATION-803) java8 lambda improvements

[Matt Juntunen (Jira)]

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

Matt Juntunen closed CONFIGURATION-803.
---

v2.8.0 released

> java8 lambda improvements 
> --
>
> Key: CONFIGURATION-803
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-803
> Project: Commons Configuration
>  Issue Type: Sub-task
>Reporter: Arturo Bernal
>Priority: Minor
> Fix For: 2.8.0
>
>
> * Use Anonymous type
>  * Replace lambda with method reference
>  * Replace loop with Collection.removeIf()
>  * Use Single Map



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (CONFIGURATION-801) Remove redundant initializer

[Matt Juntunen (Jira)]

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

Matt Juntunen closed CONFIGURATION-801.
---

v2.8.0 released

> Remove redundant initializer
> 
>
> Key: CONFIGURATION-801
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-801
> Project: Commons Configuration
>  Issue Type: Sub-task
>Reporter: Arturo Bernal
>Priority: Minor
> Fix For: 2.8.0
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (CONFIGURATION-808) DefaultListDelimiterHandler.escapeList working only for List

[Matt Juntunen (Jira)]

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

Matt Juntunen closed CONFIGURATION-808.
---

v2.8.0 released

> DefaultListDelimiterHandler.escapeList working only for List
> 
>
> Key: CONFIGURATION-808
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-808
> Project: Commons Configuration
>  Issue Type: Bug
>Reporter: Cedomir Igaly
>Priority: Minor
> Fix For: 2.8.0
>
>
> When DefaultListDelimiterHandler.escapeList is invoked with list of anything 
> except String, it is throwing exception:
> java.lang.ArrayStoreException: java.lang.Integer at 
> org.apache.commons.configuration2.convert.DefaultListDelimiterHandler.escapeList(DefaultListDelimiterHandler.java:110)
>  
> Reason: {color:#00}escapedValues{color} is created as String array, but 
> assigned to Object array
>  
> {color:#0033b3}final {color}{color:#00}Object{color}[] 
> {color:#00}escapedValues {color}= {color:#0033b3}new 
> {color}String[values.size()];
>  
> later Object returned from escape is attempted to store into (String) array:
> {color:#00}escapedValues{color}[idx++] = escape({color:#00}v{color}, 
> transformer);
>  
> Suggested solution is to create escapedValues as Object array:
> {color:#0033b3}final {color}{color:#00}Object{color}[] 
> {color:#00}escapedValues {color}= {color:#0033b3}new 
> {color}Object[values.size()];



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (CONFIGURATION-804) Redundant local variable

[Matt Juntunen (Jira)]

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

Matt Juntunen closed CONFIGURATION-804.
---

v2.8.0 released

> Redundant local variable
> 
>
> Key: CONFIGURATION-804
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-804
> Project: Commons Configuration
>  Issue Type: Sub-task
>Reporter: Arturo Bernal
>Priority: Minor
> Fix For: 2.8.0
>
>
> Remove unnecessary local variables, which add nothing to the 
> comprehensibility of a method.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (CONFIGURATION-813) Support javamail 2.0 in Configuration (package renamed, javax -> jakarta)

[Matt Juntunen (Jira)]

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

Matt Juntunen closed CONFIGURATION-813.
---

v2.8.0 released

> Support javamail 2.0 in Configuration (package renamed, javax -> jakarta)
> -
>
> Key: CONFIGURATION-813
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-813
> Project: Commons Configuration
>  Issue Type: Bug
>Reporter: Bruno P. Kinoshita
>Priority: Major
> Fix For: 2.8.0
>
>
> Via dependabot, I will update the PR with a tentative fix.
>  
> https://github.com/apache/commons-configuration/pull/107



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (CONFIGURATION-800) Minor improvements

[Matt Juntunen (Jira)]

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

Matt Juntunen closed CONFIGURATION-800.
---

v2.8.0 released

> Minor improvements
> --
>
> Key: CONFIGURATION-800
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-800
> Project: Commons Configuration
>  Issue Type: Bug
>Reporter: Arturo Bernal
>Priority: Minor
> Fix For: 2.8.0
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (CONFIGURATION-789) Add ImmutableConfiguration.getEnum() methods

[Matt Juntunen (Jira)]

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

Matt Juntunen closed CONFIGURATION-789.
---

v2.8.0 released

> Add ImmutableConfiguration.getEnum() methods
> 
>
> Key: CONFIGURATION-789
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-789
> Project: Commons Configuration
>  Issue Type: New Feature
>  Components: Type conversion
>Reporter: Gary D. Gregory
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.8.0
>
>
> Add {{ImmutableConfiguration.getEnum}} methods:
>  * org.apache.commons.configuration2.ImmutableConfiguration.getEnum(String, 
> Class)
>  * org.apache.commons.configuration2.ImmutableConfiguration.getEnum(String, 
> Class, T)
> {code:java}
> /**
>  * Gets an enum associated with the given configuration key.
>  *
>  * @param  The enum type whose constant is to be returned.
>  * @param enumType the \{@code Class} object of the enum type from which to 
> return a constant
>  * @param key The configuration key.
>  * @return The associated enum.
>  *
>  * @throws org.apache.commons.configuration2.ex.ConversionException is thrown 
> if the key maps to an object that
>  * is not a String.
>  * @since 2.8
>  */
>  default > T getEnum(String key, Class enumType)
> {code}
> and
> {code:java}
> /**
>  * Gets the enum associated with the given configuration key. If the key 
> doesn't map to an existing object, the
>  * default value is returned.
>  * 
>  * @param  The enum type whose constant is to be returned.
>  * @param key The configuration key.
>  * @param enumType the \{@code Class} object of the enum type from which to 
> return a constant
>  * @param defaultValue The default value.
>  * @return The associated enum if key is found and has valid format, default 
> value otherwise.
>  *
>  * @throws org.apache.commons.configuration2.ex.ConversionException is thrown 
> if the key maps to an object that is
>  * not a Enum.
>  * @since 2.8
>  */
>  default > T getEnum(String key, Class enumType, T 
> defaultValue) 
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (CONFIGURATION-805) Use try with resource

[Matt Juntunen (Jira)]

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

Matt Juntunen closed CONFIGURATION-805.
---

v2.8.0 released

> Use try with resource 
> --
>
> Key: CONFIGURATION-805
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-805
> Project: Commons Configuration
>  Issue Type: Sub-task
>Reporter: Arturo Bernal
>Priority: Major
> Fix For: 2.8.0
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (CONFIGURATION-802) Use final

[Matt Juntunen (Jira)]

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

Matt Juntunen closed CONFIGURATION-802.
---

v2.8.0 released

> Use final
> -
>
> Key: CONFIGURATION-802
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-802
> Project: Commons Configuration
>  Issue Type: Sub-task
>Reporter: Arturo Bernal
>Priority: Major
> Fix For: 2.8.0
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (CONFIGURATION-794) Unclosed file handle when reading config from JAR file URL

[Matt Juntunen (Jira)]

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

Matt Juntunen closed CONFIGURATION-794.
---

v2.8.0 released

> Unclosed file handle when reading config from JAR file URL
> --
>
> Key: CONFIGURATION-794
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-794
> Project: Commons Configuration
>  Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Robin Jansohn
>Priority: Major
> Fix For: 2.8.0
>
>
> We read a properties file which is included in a JAR file. Unfortunately we 
> cannot find any method to close the opened file handle after reading the 
> properties.
> This currently means that the JAR file can only be deleted after the JVM 
> shuts down. I'll open a PR which shows the behavior.
> We currently run our code mostly on Windows systems and Oracle JDK8.
> PR: https://github.com/apache/commons-configuration/pull/76



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (CONFIGURATION-790) Update optional com.fasterxml.jackson.core:jackson-databind from 2.10.3 to 2.11.1

[Matt Juntunen (Jira)]

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

Matt Juntunen closed CONFIGURATION-790.
---

v2.8.0 released

> Update optional com.fasterxml.jackson.core:jackson-databind from 2.10.3 to 
> 2.11.1
> -
>
> Key: CONFIGURATION-790
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-790
> Project: Commons Configuration
>  Issue Type: New Feature
>Reporter: Gary D. Gregory
>Priority: Major
> Fix For: 2.8.0
>
>
> Update optional com.fasterxml.jackson.core:jackson-databind from 2.10.3 to 
> 2.11.0.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (CONFIGURATION-787) Update from Apache Commons Lang 3.9 to 3.11.

[Matt Juntunen (Jira)]

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

Matt Juntunen closed CONFIGURATION-787.
---

v2.8.0 released

> Update from Apache Commons Lang 3.9 to 3.11.
> 
>
> Key: CONFIGURATION-787
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-787
> Project: Commons Configuration
>  Issue Type: Improvement
>Reporter: Gary D. Gregory
>Priority: Major
> Fix For: 2.8.0
>
>
> Update from Apache Commons Lang 3.9 to 3.11.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (CONFIGURATION-764) Default date lookup can not work for some specific format

[Matt Juntunen (Jira)]

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

Matt Juntunen closed CONFIGURATION-764.
---

v2.8.0 released

> Default date lookup can not work for some specific format
> -
>
> Key: CONFIGURATION-764
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-764
> Project: Commons Configuration
>  Issue Type: Bug
>  Components: Interpolation
>Affects Versions: 2.6
> Environment: Java 1.8.0_144,
> Windows 10/Linux
>Reporter: Ning Zhang
>Priority: Major
> Fix For: 2.8.0
>
> Attachments: 0001-Fix-default-date-lookup-issue.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> When default date lookup is like: *${date:MM}/${date:ddHHmmss}*
> It will encounter one exception like:
> _java.lang.IllegalArgumentException: Illegal pattern character 't'_
> But if change date lookup format to : /*${date:MM}/${date:ddHHmmss}*
> There will be not such issue anymore.
> After investigation, found it is caused by _interpolate_ method in 
> _ConfigurationInterpolator.java_.
> For the input date lookup format, it is will be taken as single variable via 
> _looksLikeSingleVariable_,
> so default date lookup will try to format the date directly then throw one 
> exception.
> Attached patch is trying to catch the exception then return null, substitutor 
> will continue to work.
>  
> PR: https://github.com/apache/commons-configuration/pull/36



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (CONFIGURATION-753) Handling of interpolation is inconsistent

[Matt Juntunen (Jira)]

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

Matt Juntunen closed CONFIGURATION-753.
---

v2.8.0 released

> Handling of interpolation is inconsistent
> -
>
> Key: CONFIGURATION-753
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-753
> Project: Commons Configuration
>  Issue Type: Bug
>  Components: Interpolation
>Affects Versions: 2.5
> Environment: Java 8, Configurations2 2.5
>Reporter: Peter
>Assignee: Matt Juntunen
>Priority: Major
> Fix For: 2.8.0
>
> Attachments: test.properties
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> If a key is repeated in a configuration and then used in an interpolation 
> elsewhere, the behaviour is inconsistent. There are other tickets/discussions 
> about whether it should just pick the first value or not, but I don't think 
> it should do both.
> {code:java|title=/tmp/test.properties}
> abc = hello
> abc = world
> foo.one = ${abc}
> foo.two = prefix ${abc} suffix
> {code}
> {code:java|title=Demo.java (main)}
> Parameters params = new Parameters();
> FileBasedConfigurationBuilder builder = new 
> FileBasedConfigurationBuilder(PropertiesConfiguration.class)
> .configure(params.fileBased()
> .setFileName("/tmp/test.properties")
>   );
> try {
> FileBasedConfiguration config = builder.getConfiguration();
> System.out.println(config.getString("foo.one"));
> System.out.println(config.getString("foo.two"));
> } catch (ConfigurationException cex) {
> // pass
> }
> {code}
> The output from the above is
> {noformat}
> hello 
> prefix [hello, world] suffix
> {noformat}
> In the first case, only the first value is being matched, in the second both 
> values (and [, ]) are used.
> I'd expect the output to either be
> {noformat:title=First value only}
> hello
> prefix hello suffix
> {noformat}
> or
> {noformat:title=Both values used}
> [hello, world]
> prefix [hello, world] suffix
> {noformat}
> I can work around whichever style is chosen but think it'd be much more 
> intuitive if both cases were handled the same.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (CONFIGURATION-813) Support javamail 2.0 in Configuration (package renamed, javax -> jakarta)

[Matt Juntunen (Jira)]

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

Matt Juntunen updated CONFIGURATION-813:

Fix Version/s: 2.8.0

> Support javamail 2.0 in Configuration (package renamed, javax -> jakarta)
> -
>
> Key: CONFIGURATION-813
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-813
> Project: Commons Configuration
>  Issue Type: Bug
>Reporter: Bruno P. Kinoshita
>Priority: Major
> Fix For: 2.8.0
>
>
> Via dependabot, I will update the PR with a tentative fix.
>  
> https://github.com/apache/commons-configuration/pull/107



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Resolved] (CONFIGURATION-813) Support javamail 2.0 in Configuration (package renamed, javax -> jakarta)

[Matt Juntunen (Jira)]

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

Matt Juntunen resolved CONFIGURATION-813.
-
Resolution: Done

> Support javamail 2.0 in Configuration (package renamed, javax -> jakarta)
> -
>
> Key: CONFIGURATION-813
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-813
> Project: Commons Configuration
>  Issue Type: Bug
>Reporter: Bruno P. Kinoshita
>Priority: Major
>
> Via dependabot, I will update the PR with a tentative fix.
>  
> https://github.com/apache/commons-configuration/pull/107



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (CONFIGURATION-813) Support javamail 2.0 in Configuration (package renamed, javax -> jakarta)

[Matt Juntunen (Jira)]

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17553863#comment-17553863
 ] 

Matt Juntunen commented on CONFIGURATION-813:
-

Added in commit 079cf7176989fb91d622a6a06f1fb7023cb79a25.

> Support javamail 2.0 in Configuration (package renamed, javax -> jakarta)
> -
>
> Key: CONFIGURATION-813
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-813
> Project: Commons Configuration
>  Issue Type: Bug
>Reporter: Bruno P. Kinoshita
>Priority: Major
>
> Via dependabot, I will update the PR with a tentative fix.
>  
> https://github.com/apache/commons-configuration/pull/107



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (CONFIGURATION-813) Support javamail 2.0 in Configuration (package renamed, javax -> jakarta)

[Matt Juntunen (Jira)]

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17553858#comment-17553858
 ] 

Matt Juntunen commented on CONFIGURATION-813:
-

After the discussion on the mailing list 
[here|https://lists.apache.org/thread/xpp1vf7q5dj2v0z9dyjj87nvhbgj1xox], we 
have decided to move back to the set of changes from the original PR (#107). 
This includes support for both the javax.* and the jakarta* mailapi namespaces 
since making the change would require some users to update their code, thereby 
breaking "implicit" binary compatibility.

The new PR (with the changes rebased on master) is 
https://github.com/apache/commons-configuration/pull/186.

> Support javamail 2.0 in Configuration (package renamed, javax -> jakarta)
> -
>
> Key: CONFIGURATION-813
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-813
> Project: Commons Configuration
>  Issue Type: Bug
>Reporter: Bruno P. Kinoshita
>Priority: Major
>
> Via dependabot, I will update the PR with a tentative fix.
>  
> https://github.com/apache/commons-configuration/pull/107



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Commented] (CONFIGURATION-813) Support javamail 2.0 in Configuration (package renamed, javax -> jakarta)

[Matt Juntunen (Jira)]

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17552490#comment-17552490
 ] 

Matt Juntunen commented on CONFIGURATION-813:
-

I've replaced the PR above with this one: 
https://github.com/apache/commons-configuration/pull/185

> Support javamail 2.0 in Configuration (package renamed, javax -> jakarta)
> -
>
> Key: CONFIGURATION-813
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-813
> Project: Commons Configuration
>  Issue Type: Bug
>Reporter: Bruno P. Kinoshita
>Priority: Major
>
> Via dependabot, I will update the PR with a tentative fix.
>  
> https://github.com/apache/commons-configuration/pull/107



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Commented] (CONFIGURATION-753) Handling of interpolation is inconsistent

[Matt Juntunen (Jira)]

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17539898#comment-17539898
 ] 

Matt Juntunen commented on CONFIGURATION-753:
-

Done in commit 454fa0ce34fee5f182e8dcd83af77947d5dfddaa

> Handling of interpolation is inconsistent
> -
>
> Key: CONFIGURATION-753
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-753
> Project: Commons Configuration
>  Issue Type: Bug
>  Components: Interpolation
>Affects Versions: 2.5
> Environment: Java 8, Configurations2 2.5
>Reporter: Peter
>Assignee: Matt Juntunen
>Priority: Major
> Fix For: 2.8.0
>
> Attachments: test.properties
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> If a key is repeated in a configuration and then used in an interpolation 
> elsewhere, the behaviour is inconsistent. There are other tickets/discussions 
> about whether it should just pick the first value or not, but I don't think 
> it should do both.
> {code:java|title=/tmp/test.properties}
> abc = hello
> abc = world
> foo.one = ${abc}
> foo.two = prefix ${abc} suffix
> {code}
> {code:java|title=Demo.java (main)}
> Parameters params = new Parameters();
> FileBasedConfigurationBuilder builder = new 
> FileBasedConfigurationBuilder(PropertiesConfiguration.class)
> .configure(params.fileBased()
> .setFileName("/tmp/test.properties")
>   );
> try {
> FileBasedConfiguration config = builder.getConfiguration();
> System.out.println(config.getString("foo.one"));
> System.out.println(config.getString("foo.two"));
> } catch (ConfigurationException cex) {
> // pass
> }
> {code}
> The output from the above is
> {noformat}
> hello 
> prefix [hello, world] suffix
> {noformat}
> In the first case, only the first value is being matched, in the second both 
> values (and [, ]) are used.
> I'd expect the output to either be
> {noformat:title=First value only}
> hello
> prefix hello suffix
> {noformat}
> or
> {noformat:title=Both values used}
> [hello, world]
> prefix [hello, world] suffix
> {noformat}
> I can work around whichever style is chosen but think it'd be much more 
> intuitive if both cases were handled the same.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Resolved] (CONFIGURATION-753) Handling of interpolation is inconsistent

[Matt Juntunen (Jira)]

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

Matt Juntunen resolved CONFIGURATION-753.
-
Resolution: Fixed

> Handling of interpolation is inconsistent
> -
>
> Key: CONFIGURATION-753
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-753
> Project: Commons Configuration
>  Issue Type: Bug
>  Components: Interpolation
>Affects Versions: 2.5
> Environment: Java 8, Configurations2 2.5
>Reporter: Peter
>Assignee: Matt Juntunen
>Priority: Major
> Fix For: 2.8.0
>
> Attachments: test.properties
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> If a key is repeated in a configuration and then used in an interpolation 
> elsewhere, the behaviour is inconsistent. There are other tickets/discussions 
> about whether it should just pick the first value or not, but I don't think 
> it should do both.
> {code:java|title=/tmp/test.properties}
> abc = hello
> abc = world
> foo.one = ${abc}
> foo.two = prefix ${abc} suffix
> {code}
> {code:java|title=Demo.java (main)}
> Parameters params = new Parameters();
> FileBasedConfigurationBuilder builder = new 
> FileBasedConfigurationBuilder(PropertiesConfiguration.class)
> .configure(params.fileBased()
> .setFileName("/tmp/test.properties")
>   );
> try {
> FileBasedConfiguration config = builder.getConfiguration();
> System.out.println(config.getString("foo.one"));
> System.out.println(config.getString("foo.two"));
> } catch (ConfigurationException cex) {
> // pass
> }
> {code}
> The output from the above is
> {noformat}
> hello 
> prefix [hello, world] suffix
> {noformat}
> In the first case, only the first value is being matched, in the second both 
> values (and [, ]) are used.
> I'd expect the output to either be
> {noformat:title=First value only}
> hello
> prefix hello suffix
> {noformat}
> or
> {noformat:title=Both values used}
> [hello, world]
> prefix [hello, world] suffix
> {noformat}
> I can work around whichever style is chosen but think it'd be much more 
> intuitive if both cases were handled the same.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (CONFIGURATION-753) Handling of interpolation is inconsistent

[Matt Juntunen (Jira)]

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17539897#comment-17539897
 ] 

Matt Juntunen commented on CONFIGURATION-753:
-

No problem! I'm hoping to have the next version out soon.

> Handling of interpolation is inconsistent
> -
>
> Key: CONFIGURATION-753
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-753
> Project: Commons Configuration
>  Issue Type: Bug
>  Components: Interpolation
>Affects Versions: 2.5
> Environment: Java 8, Configurations2 2.5
>Reporter: Peter
>Assignee: Matt Juntunen
>Priority: Major
> Fix For: 2.8.0
>
> Attachments: test.properties
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> If a key is repeated in a configuration and then used in an interpolation 
> elsewhere, the behaviour is inconsistent. There are other tickets/discussions 
> about whether it should just pick the first value or not, but I don't think 
> it should do both.
> {code:java|title=/tmp/test.properties}
> abc = hello
> abc = world
> foo.one = ${abc}
> foo.two = prefix ${abc} suffix
> {code}
> {code:java|title=Demo.java (main)}
> Parameters params = new Parameters();
> FileBasedConfigurationBuilder builder = new 
> FileBasedConfigurationBuilder(PropertiesConfiguration.class)
> .configure(params.fileBased()
> .setFileName("/tmp/test.properties")
>   );
> try {
> FileBasedConfiguration config = builder.getConfiguration();
> System.out.println(config.getString("foo.one"));
> System.out.println(config.getString("foo.two"));
> } catch (ConfigurationException cex) {
> // pass
> }
> {code}
> The output from the above is
> {noformat}
> hello 
> prefix [hello, world] suffix
> {noformat}
> In the first case, only the first value is being matched, in the second both 
> values (and [, ]) are used.
> I'd expect the output to either be
> {noformat:title=First value only}
> hello
> prefix hello suffix
> {noformat}
> or
> {noformat:title=Both values used}
> [hello, world]
> prefix [hello, world] suffix
> {noformat}
> I can work around whichever style is chosen but think it'd be much more 
> intuitive if both cases were handled the same.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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
> >> 

[jira] [Commented] (CONFIGURATION-764) Default date lookup can not work for some specific format

[Matt Juntunen (Jira)]

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17537247#comment-17537247
 ] 

Matt Juntunen commented on CONFIGURATION-764:
-

I've submitted a new PR 
(https://github.com/apache/commons-configuration/pull/182) that changes the 
logic in {{looksLikeSingleVariable}} to better detect inputs like this. This 
approach requires fewer changes and does not suppress any exceptions. Let me 
know what you think.

> Default date lookup can not work for some specific format
> -
>
> Key: CONFIGURATION-764
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-764
> Project: Commons Configuration
>  Issue Type: Bug
>  Components: Interpolation
>Affects Versions: 2.6
> Environment: Java 1.8.0_144,
> Windows 10/Linux
>Reporter: Ning Zhang
>Priority: Major
> Attachments: 0001-Fix-default-date-lookup-issue.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> When default date lookup is like: *${date:MM}/${date:ddHHmmss}*
> It will encounter one exception like:
> _java.lang.IllegalArgumentException: Illegal pattern character 't'_
> But if change date lookup format to : /*${date:MM}/${date:ddHHmmss}*
> There will be not such issue anymore.
> After investigation, found it is caused by _interpolate_ method in 
> _ConfigurationInterpolator.java_.
> For the input date lookup format, it is will be taken as single variable via 
> _looksLikeSingleVariable_,
> so default date lookup will try to format the date directly then throw one 
> exception.
> Attached patch is trying to catch the exception then return null, substitutor 
> will continue to work.
>  
> PR: https://github.com/apache/commons-configuration/pull/36



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (CONFIGURATION-753) Handling of interpolation is inconsistent

[Matt Juntunen (Jira)]

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17537236#comment-17537236
 ] 

Matt Juntunen commented on CONFIGURATION-753:
-

I've added a new PR (https://github.com/apache/commons-configuration/pull/181) 
with an expanded version of [~tpoliaw]'s changes. The basic idea is to expose 
the string conversion logic of {{ConfigurationInterpolator}} as a configurable 
property, with a default that closely resembles the logic in 
{{DefaultConversionHandler}}. This makes the interpolation behavior consistent 
while also allowing users to customize it on their own if this does not meet 
their needs.

Thoughts?

> Handling of interpolation is inconsistent
> -
>
> Key: CONFIGURATION-753
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-753
> Project: Commons Configuration
>  Issue Type: Bug
>  Components: Interpolation
>Affects Versions: 2.5
> Environment: Java 8, Configurations2 2.5
>Reporter: Peter
>Priority: Major
> Attachments: test.properties
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> If a key is repeated in a configuration and then used in an interpolation 
> elsewhere, the behaviour is inconsistent. There are other tickets/discussions 
> about whether it should just pick the first value or not, but I don't think 
> it should do both.
> {code:java|title=/tmp/test.properties}
> abc = hello
> abc = world
> foo.one = ${abc}
> foo.two = prefix ${abc} suffix
> {code}
> {code:java|title=Demo.java (main)}
> Parameters params = new Parameters();
> FileBasedConfigurationBuilder builder = new 
> FileBasedConfigurationBuilder(PropertiesConfiguration.class)
> .configure(params.fileBased()
> .setFileName("/tmp/test.properties")
>   );
> try {
> FileBasedConfiguration config = builder.getConfiguration();
> System.out.println(config.getString("foo.one"));
> System.out.println(config.getString("foo.two"));
> } catch (ConfigurationException cex) {
> // pass
> }
> {code}
> The output from the above is
> {noformat}
> hello 
> prefix [hello, world] suffix
> {noformat}
> In the first case, only the first value is being matched, in the second both 
> values (and [, ]) are used.
> I'd expect the output to either be
> {noformat:title=First value only}
> hello
> prefix hello suffix
> {noformat}
> or
> {noformat:title=Both values used}
> [hello, world]
> prefix [hello, world] suffix
> {noformat}
> I can work around whichever style is chosen but think it'd be much more 
> intuitive if both cases were handled the same.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (CONFIGURATION-753) Handling of interpolation is inconsistent

[Matt Juntunen (Jira)]

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17534850#comment-17534850
 ] 

Matt Juntunen commented on CONFIGURATION-753:
-

Coming in late to this discussion...

The main cause of the inconsistency here seems to be the interaction between 
{{DefaultConversionHandler}} and {{ConfigurationInterpolator}}. In the case 
where the property value consists of only a variable reference, the 
{{ConfigurationInterpolator}} returns the actual collection object instead of a 
string. {{DefaultConversionHandler}} then attempts to convert the "complex" 
object to a string and chooses the first entry from the collection. However, if 
the property value contains more than just the variable reference, then 
{{ConfigurationInterpolator}} uses {{StringSubstitutor}} to construct the final 
string. {{StringSubstitutor}} does not contain the complex string conversion 
logic that {{DefaultConversionHandler}} has and simply uses 
{{Objects.toString()}}, producing the inconsistency noted in this ticket.

Here are my thoughts on how to address this:
1. Rework the API so that {{ConfigurationInterpolator}} can call back into a 
{{ConversionHandler}} to convert values to strings. This would produce the most 
consistent results overall and would prevent us from having similar conversion 
logic in both classes. 
2. Do nothing. We can document the fact that single variable interpolation can 
return different values than interpolation with variables and non-variables. I 
believe this is internally consistent behavior even though it may not be the 
expected behavior at times.

I plan on looking into the first option more. Thoughts?

> Handling of interpolation is inconsistent
> -
>
> Key: CONFIGURATION-753
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-753
> Project: Commons Configuration
>  Issue Type: Bug
>  Components: Interpolation
>Affects Versions: 2.5
> Environment: Java 8, Configurations2 2.5
>Reporter: Peter
>Priority: Major
> Attachments: test.properties
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> If a key is repeated in a configuration and then used in an interpolation 
> elsewhere, the behaviour is inconsistent. There are other tickets/discussions 
> about whether it should just pick the first value or not, but I don't think 
> it should do both.
> {code:java|title=/tmp/test.properties}
> abc = hello
> abc = world
> foo.one = ${abc}
> foo.two = prefix ${abc} suffix
> {code}
> {code:java|title=Demo.java (main)}
> Parameters params = new Parameters();
> FileBasedConfigurationBuilder builder = new 
> FileBasedConfigurationBuilder(PropertiesConfiguration.class)
> .configure(params.fileBased()
> .setFileName("/tmp/test.properties")
>   );
> try {
> FileBasedConfiguration config = builder.getConfiguration();
> System.out.println(config.getString("foo.one"));
> System.out.println(config.getString("foo.two"));
> } catch (ConfigurationException cex) {
> // pass
> }
> {code}
> The output from the above is
> {noformat}
> hello 
> prefix [hello, world] suffix
> {noformat}
> In the first case, only the first value is being matched, in the second both 
> values (and [, ]) are used.
> I'd expect the output to either be
> {noformat:title=First value only}
> hello
> prefix hello suffix
> {noformat}
> or
> {noformat:title=Both values used}
> [hello, world]
> prefix [hello, world] suffix
> {noformat}
> I can work around whichever style is chosen but think it'd be much more 
> intuitive if both cases were handled the same.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[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

[jira] [Resolved] (CONFIGURATION-810) Refactor DummyLayout in TestPropertiesConfiguration to improve test design

[Matt Juntunen (Jira)]

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

Matt Juntunen resolved CONFIGURATION-810.
-
Resolution: Won't Fix

> Refactor DummyLayout in TestPropertiesConfiguration to improve test design
> --
>
> Key: CONFIGURATION-810
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-810
> Project: Commons Configuration
>  Issue Type: Improvement
>Reporter: Xiao Wang
>Priority: Minor
>
> h3. Description
> I noticed that there is a test class 
> [DummyLayout|https://github.com/apache/commons-configuration/blob/66b4f4eb73b276d041debaad80af3074ccb359bd/src/test/java/org/apache/commons/configuration2/TestPropertiesConfiguration.java#L91]
>  implements production class 
> [PropertiesConfigurationLayout|https://github.com/apache/commons-configuration/blob/66b4f4eb73b276d041debaad80af3074ccb359bd/src/main/java/org/apache/commons/configuration2/PropertiesConfigurationLayout.java#L102]
>  to assist testing method [PropertiesConfiguration.propertyLoaded(String, 
> String, 
> Deque)|https://github.com/apache/commons-configuration/blob/66b4f4eb73b276d041debaad80af3074ccb359bd/src/main/java/org/apache/commons/configuration2/PropertiesConfiguration.java#L1467].
>  This might not be the best priactice in unit testing and can be improved by 
> leveraging mocking frameworks.
> h3. Current Implementation
>  * {{DummyLayout}} extends {{PropertiesConfigurationLayout}} and creates a 
> new variable to keep tracking of the method invocation status for 
> {{load(PropertiesConfiguration, Reader)}}.
>  * In test cases, after executing 
> {{PropertiesConfiguration.propertyLoaded(String, String, Deque)}}, the 
> new variable will be used in assertion statement to check the execution 
> status of {{load(PropertiesConfiguration, Reader)}}.
> h3. Proposed Implementation
>  * Replace {{DummyLayout}} with a mocking object created by Mockito.
>  * Remove the {{int}} variable that used to keep tracking the invocation 
> times of {{load(PropertiesConfiguration, Reader)}}.
>  * Use {{Mockito.verify()}} to check execution status of 
> {{load(PropertiesConfiguration, Reader)}}.
> h3. Motivation
>  * Decouple test class {{DummyLayout}} from production class 
> {{PropertiesConfigurationLayout}}.
>  * Make test logic more clear by removing the overridden method in 
> {{DummyLayout}}.
>  * Make test condition more explict by directly using {{Mockito.verify()}} to 
> verify method execution status.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (CONFIGURATION-810) Refactor DummyLayout in TestPropertiesConfiguration to improve test design

[Matt Juntunen (Jira)]

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532005#comment-17532005
 ] 

Matt Juntunen commented on CONFIGURATION-810:
-

Thank you for your PR! Your rationale is good and your issue description is 
very clearly structured. However, I don't believe this change is necessary for 
the following reasons:
1. It adds a new dependency on mockito when, for better or worse, the project 
already has a dependency on [easymock|https://easymock.org/]. Having two 
mocking frameworks in the same project will be confusing.
2. I typically avoid mocking or otherwise modifying the actual object under 
test because it is not obvious how the mocking framework is modifying or 
extending the object. With {{DummyLayout}}, the modification is clear: the 
class under test is being extended, a single method is overridden, and all 
other behavior is the same. Note that I'm not saying that mockito isn't doing 
this internally; I'm saying that this fact is not clear from just looking at 
the test.
3. The use case for {{DummyLayout}} is very simple and not much longer than the 
mocked version.

> Refactor DummyLayout in TestPropertiesConfiguration to improve test design
> --
>
> Key: CONFIGURATION-810
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-810
> Project: Commons Configuration
>  Issue Type: Improvement
>Reporter: Xiao Wang
>Priority: Minor
>
> h3. Description
> I noticed that there is a test class 
> [DummyLayout|https://github.com/apache/commons-configuration/blob/66b4f4eb73b276d041debaad80af3074ccb359bd/src/test/java/org/apache/commons/configuration2/TestPropertiesConfiguration.java#L91]
>  implements production class 
> [PropertiesConfigurationLayout|https://github.com/apache/commons-configuration/blob/66b4f4eb73b276d041debaad80af3074ccb359bd/src/main/java/org/apache/commons/configuration2/PropertiesConfigurationLayout.java#L102]
>  to assist testing method [PropertiesConfiguration.propertyLoaded(String, 
> String, 
> Deque)|https://github.com/apache/commons-configuration/blob/66b4f4eb73b276d041debaad80af3074ccb359bd/src/main/java/org/apache/commons/configuration2/PropertiesConfiguration.java#L1467].
>  This might not be the best priactice in unit testing and can be improved by 
> leveraging mocking frameworks.
> h3. Current Implementation
>  * {{DummyLayout}} extends {{PropertiesConfigurationLayout}} and creates a 
> new variable to keep tracking of the method invocation status for 
> {{load(PropertiesConfiguration, Reader)}}.
>  * In test cases, after executing 
> {{PropertiesConfiguration.propertyLoaded(String, String, Deque)}}, the 
> new variable will be used in assertion statement to check the execution 
> status of {{load(PropertiesConfiguration, Reader)}}.
> h3. Proposed Implementation
>  * Replace {{DummyLayout}} with a mocking object created by Mockito.
>  * Remove the {{int}} variable that used to keep tracking the invocation 
> times of {{load(PropertiesConfiguration, Reader)}}.
>  * Use {{Mockito.verify()}} to check execution status of 
> {{load(PropertiesConfiguration, Reader)}}.
> h3. Motivation
>  * Decouple test class {{DummyLayout}} from production class 
> {{PropertiesConfigurationLayout}}.
>  * Make test logic more clear by removing the overridden method in 
> {{DummyLayout}}.
>  * Make test condition more explict by directly using {{Mockito.verify()}} to 
> verify method execution status.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

Re: Commons Configuration Release Plan

[Matt Juntunen]

Hello,

I could go ahead and try to release this. It will have to be after
this weekend, however, since I will be busy with family. (It's
Mother's Day in the US.)

Regards,
Matt J

On Wed, May 4, 2022 at 8:19 AM Gary Gregory  wrote:
>
> Different components have different levels of maturity and interest for
> people here who are volunteering. Update frequency is not correlated to
> quality.
>
> Gary
>
> On Wed, May 4, 2022, 07:28 Amaladhithyan Krishnamoorthy <
> amaladhithyan.krishnamoor...@ericsson.com> wrote:
>
> > Hi Gary,
> >
> >
> >
> >  We are not looking for any change or feature specifically.
> >
> >
> >
> > According to an internal guideline we follow in our organization any FOSS
> > that hasn’t received an update or new release in 2 years (approx.) has to
> > evaluated for replacement.
> >
> >   Since commons-configuration last release was only in 2020, we wanted
> > to know if there will any release in the future so that we can make a call
> > to either go for a replacement or hold-on until an update is received. To
> > make this decision we would want to know if and when there will be an
> > update to commons-configuration.
> >
> >
> >
> >Also, we observed from the release history that
> > common-configuration has had at least 2 updates an year until 2020. Any
> > reason why we have not seen an update for more than 2 years?
> >
> >
> >
> >   Thanks,
> >
> > Amal
> >
> >
> >
> > *From:* Gary Gregory 
> > *Sent:* Wednesday, May 4, 2022 4:21 PM
> > *To:* Commons Users List 
> > *Cc:* M Vasanthakumar ; Amaladhithyan
> > Krishnamoorthy 
> > *Subject:* Re: Commons Configuration Release Plan
> >
> >
> >
> > Hi,
> >
> >
> >
> > Are you looking for a specific change?
> >
> >
> >
> > It's on my to do list but I do not have a date. Within a couple of months
> > maybe, after we release other components that have higher priority for me
> > ATM.
> >
> >
> >
> > Gary
> >
> >
> >
> > On Wed, May 4, 2022, 06:46 Shivaraj Sivasankaran <
> > shivaraj.sivasanka...@ericsson.com.invalid> wrote:
> >
> > +Update the Subject+++
> > Hi,
> >
> > Am Shivaraj from Ericsson India Global Private Limited, we have our own
> > software to meet the business need and we used below FOSS to achieve
> > certain functionalities. Since we planned to upgrade the below component
> > and found that the product is last released in Mar'2020 - Apache
> > Configuration 2.7, is there any update/release planned in near future if so
> > please revert on the planned release date.
> >
> >
> > Vendor
> > Software Name
> > Version
> > Apache
> > Commons Configuration
> > 1.9
> >
> > Regards,
> > Shivaraj Sivasankaran.
> >
> >

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

[jira] [Resolved] (GEOMETRY-147) BoundsXD Linecastable

[Matt Juntunen (Jira)]

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

Matt Juntunen resolved GEOMETRY-147.

Resolution: Done

> BoundsXD Linecastable
> -
>
> Key: GEOMETRY-147
> URL: https://issues.apache.org/jira/browse/GEOMETRY-147
> Project: Commons Geometry
>  Issue Type: New Feature
>    Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Make the {{Bounds2D}} and {{Bounds3D}} classes implement {{Linecastable}}. 
> Use the 
> ["slabs"|https://education.siggraph.org/static/HyperGraph/raytrace/rtinter3.htm]
>  algorithm to determine intersection points.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (GEOMETRY-147) BoundsXD Linecastable

[Matt Juntunen (Jira)]

[ 
https://issues.apache.org/jira/browse/GEOMETRY-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17531473#comment-17531473
 ] 

Matt Juntunen commented on GEOMETRY-147:


Merged in commit 27b8d65ad6900af39b6036d8a00dcd8d448c99ee

> BoundsXD Linecastable
> -
>
> Key: GEOMETRY-147
> URL: https://issues.apache.org/jira/browse/GEOMETRY-147
> Project: Commons Geometry
>  Issue Type: New Feature
>    Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Make the {{Bounds2D}} and {{Bounds3D}} classes implement {{Linecastable}}. 
> Use the 
> ["slabs"|https://education.siggraph.org/static/HyperGraph/raytrace/rtinter3.htm]
>  algorithm to determine intersection points.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (GEOMETRY-144) Review API in "hull" module

[Matt Juntunen (Jira)]

[ 
https://issues.apache.org/jira/browse/GEOMETRY-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17530519#comment-17530519
 ] 

Matt Juntunen commented on GEOMETRY-144:


I'm thinking it would be useful to apply the builder pattern for convex hull 
construction. The current API in {{commons-geometry-hull}} only accepts a 
collection of points, which means that if callers do not have such a collection 
readily available, they must allocate memory for the collection, extract points 
from whatever data structure they are part of, and _then_ pass it to the convex 
hull algorithm. If we use the builder pattern, we can avoid this allocation 
overhead. For example,
{code:java}
// previous API
RegionBSPTree3D tree = ...
List pts = new ArrayList<>();
tree.boundaryStream(b -> pts.addAll(pts.getVertices()); // pts could become 
quite large here
ConvexHull3D hull = ... // create from pts

// builder API
RegionBSPTree3D tree = ...
ConvexHull3D.Builder hullBuilder = ConvexHull3D.builder(precision);
tree.boundaryStream(b -> hullBuilder.addAll(b.getVertices()));
ConvexHull3D hull = hullBuilder.build();
{code}
It may also be possible for us completely ignore particular points (and not 
even store them within the builder) if the point can be immediately determined 
to not lie on the hull.

> Review API in "hull" module
> ---
>
> Key: GEOMETRY-144
> URL: https://issues.apache.org/jira/browse/GEOMETRY-144
> Project: Commons Geometry
>  Issue Type: Task
>Reporter: Gilles Sadowski
>Assignee: Gilles Sadowski
>Priority: Minor
> Fix For: 1.1
>
>
> Review codes in the 
> [{{commons-geometry-hull}}|https://gitbox.apache.org/repos/asf?p=commons-geometry.git;a=tree;f=commons-geometry-hull;hb=HEAD]
>  module.
> (x) Minimize the public API



--
This message was sent by Atlassian Jira
(v8.20.7#820007)