[Math][All] "dist-archive" module
Hi.
Is the "dist-archive" module/directory still in use.
I noticed that the command
$ cd dist-archive && mvn assembly::single
(as documented e.g. in [1]) generates "bin" archives (".tar.gz"
and ".zip" files) that only contain the NOTICE and LICENCE
files). The "src" seem OK.
However, I also see that ".tar.gz" and ".zip" archive files[2] are
generated under each module's "target" directory that indeed
contain the expected JAR files.
I thus wonder whether the "dist-archive" is still in use.
Thanks,
Gilles
[1]
https://gitbox.apache.org/repos/asf?p=commons-numbers.git;a=blob;f=doc/release/release.howto.txt;h=284edebded17a6047b1cf8b6753d2003233ed87d;hb=HEAD#l124
[2] Those archive files also include unexpected "apidocs" directories.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Geometry] Issues (?) with the "hull" module[1]
Hello. > OK. Did I understand correctly that the functionality is already > there, with several implementations)? We only have one convex hull implementation (MonotoneChain) and that one is only for 2D. Before we release, I'd like to at least have implementations for Euclidean 2D and 3D. I'm thinking we should design the API so that we only present a single convex hull operation per dimension and keep the actual implementation private, so we can replace the algorithm if/when better alternatives become available. Regards, Matt On Mon, Jan 17, 2022 at 9:10 AM Gilles Sadowski wrote: > > Hello. > > Le lun. 17 janv. 2022 à 14:16, Matt Juntunen > a écrit : > > > > Hi Gilles, > > > > The main things I want to do on the hull module are > > - Review the public API to see if any changes need to be made. (ex: > > make AklToussaintHeuristic internal) > > Good suggestion; I'll minimize the public API.[1] > > > - Add QuickHull implementations for 2D/3D (GEOMETRY-110). This is > > currently blocked due to the need for a PointMap implementation, which > > I am working on now in GEOMETRY-142. > > OK. Did I understand correctly that the functionality is already > there, with several implementations)? If so, we could in effect > make all those private, and select a different alternative whenever > a more performant algorithm is available. > > Best, > Gilles > > [1] I've created https://issues.apache.org/jira/browse/GEOMETRY-144 > > > On Sun, Jan 16, 2022 at 12:59 PM Gilles Sadowski > > wrote: > > > > > > Hello. > > > > > > Could you remind me what work needs to be done so that this > > > functionality can make it into the next release of [Geometry]? > > > > > > Thanks, > > > Gilles > > > > > > [1] > > > https://gitbox.apache.org/repos/asf?p=commons-geometry.git;a=tree;f=commons-geometry-hull;h=a3dd796c9c418e10768cda5998f89c19e7439f28;hb=HEAD > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons JCS 3.1 based on rc2
Hi Gilles, > Am 17.01.2022 um 14:11 schrieb Gilles Sadowski : > > No; the remark is for making the reviewer's life easier, i.e just copy/paste > the command and see the build succeed. Without the environment variable, > the "javadoc" step fails IIRC. Ok, thanks for the hint. I didn’t know this. > It's not the procedure. I simply stress FTR that the release notes > become less and less what they should be, that is a summary for > human consumption that attracts the user's attention on functional > changes. [The full set of changes is always accessible through the > commits log.] > To ensure clarity for users, changes that cannot affect them should > not be listed in "changes.xml". Yes. For the sake of clarity for the user, I find the manual maintenance of changes.xml much better than other measures like commit logs or JIRA-Ticket reports. However, I’m a bit hesitant to change entries made by other committers. I guess that would require consent between all committers of a project on how to maintain the changes list. >>> There are a few changes marked incompatible. Is it expected in a minor >>> release? >> The japicmp report recommends a 0.1.0 release which it is. > > I don't understand why, but OK then… Actually, it took several changes to be reverted just to get to this state. > [ ] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because… >> >> Would you please consider voting? > > +1 > > [There are no technical issues, only communication issues that are > common problems with all the releases.] Thanks, Gilles. Bye, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons JCS 3.1 based on rc2
Hi Gilles, > Am 17.01.2022 um 14:11 schrieb Gilles Sadowski : > > No; the remark is for making the reviewer's life easier, i.e just copy/paste > the command and see the build succeed. Without the environment variable, > the "javadoc" step fails IIRC. Ok, thanks for the hint. I didn’t know this. > It's not the procedure. I simply stress FTR that the release notes > become less and less what they should be, that is a summary for > human consumption that attracts the user's attention on functional > changes. [The full set of changes is always accessible through the > commits log.] > To ensure clarity for users, changes that cannot affect them should > not be listed in "changes.xml". Yes. For the sake of clarity for the user, I find the manual maintenance of changes.xml much better than other measures like commit logs or JIRA-Ticket reports. However, I’m a bit hesitant to change entries made by other committers. I guess that would require consent between all committers of a project on how to maintain the changes list. >>> There are a few changes marked incompatible. Is it expected in a minor >>> release? >> The japicmp report recommends a 0.1.0 release which it is. > > I don't understand why, but OK then… Actually, it took several changes to be reverted just to get to this state. > [ ] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because… >> >> Would you please consider voting? > > +1 > > [There are no technical issues, only communication issues that are > common problems with all the releases.] Thanks, Gilles. Bye, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Geometry] Issues (?) with the "hull" module[1]
Hello. Le lun. 17 janv. 2022 à 14:16, Matt Juntunen a écrit : > > Hi Gilles, > > The main things I want to do on the hull module are > - Review the public API to see if any changes need to be made. (ex: > make AklToussaintHeuristic internal) Good suggestion; I'll minimize the public API.[1] > - Add QuickHull implementations for 2D/3D (GEOMETRY-110). This is > currently blocked due to the need for a PointMap implementation, which > I am working on now in GEOMETRY-142. OK. Did I understand correctly that the functionality is already there, with several implementations)? If so, we could in effect make all those private, and select a different alternative whenever a more performant algorithm is available. Best, Gilles [1] I've created https://issues.apache.org/jira/browse/GEOMETRY-144 > On Sun, Jan 16, 2022 at 12:59 PM Gilles Sadowski wrote: > > > > Hello. > > > > Could you remind me what work needs to be done so that this > > functionality can make it into the next release of [Geometry]? > > > > Thanks, > > Gilles > > > > [1] > > https://gitbox.apache.org/repos/asf?p=commons-geometry.git;a=tree;f=commons-geometry-hull;h=a3dd796c9c418e10768cda5998f89c19e7439f28;hb=HEAD - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Geometry] Issues (?) with the "hull" module[1]
Hi Gilles, The main things I want to do on the hull module are - Review the public API to see if any changes need to be made. (ex: make AklToussaintHeuristic internal) - Add QuickHull implementations for 2D/3D (GEOMETRY-110). This is currently blocked due to the need for a PointMap implementation, which I am working on now in GEOMETRY-142. Regards, Matt J On Sun, Jan 16, 2022 at 12:59 PM Gilles Sadowski wrote: > > Hello. > > Could you remind me what work needs to be done so that this > functionality can make it into the next release of [Geometry]? > > Thanks, > Gilles > > [1] > https://gitbox.apache.org/repos/asf?p=commons-geometry.git;a=tree;f=commons-geometry-hull;h=a3dd796c9c418e10768cda5998f89c19e7439f28;hb=HEAD > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons JCS 3.1 based on rc2
Hello. Le lun. 17 janv. 2022 à 13:33, Thomas Vandahl a écrit : > > Hi Gilles, > > > Am 14.01.2022 um 15:37 schrieb Gilles Sadowski : > > > >>> Maven artifacts are here: > >>> > >>> https://repository.apache.org/content/repositories/orgapachecommons-1576/org/apache/commons/commons-jcs3/3.1/ > > > > I only see one ".pom" file and one ".xml" file (with their respective > > crypto sig). > > > … and modules below > https://repository.apache.org/content/repositories/orgapachecommons-1576/org/apache/commons/commons-jcs3 Actually they _above_ link, hence my confusion! One has to click on "Parent Directory" with target https://repository.apache.org/content/repositories/orgapachecommons-1576/org/apache/commons/ in order to see the modules. > > > We should note that this command requires the environment variable > > JAVA_HOME > > to be set (otherwise the build will fail). > > > Is this a special requirement of this build? No; the remark is for making the reviewer's life easier, i.e just copy/paste the command and see the build succeed. Without the environment variable, the "javadoc" step fails IIRC. > If so, why? > > > Shall we stop cluttering what should be a summary of important changes, > > easily readable by a human, with bot-generated messages and trivial > > one-liners like "isEmpty()"? > > > I followed the directions for the release preparation at > https://commons.apache.org/releases/prepare.html and generated the release > notes with „mvn changes:announcement-generate -Prelease-notes“ and the vote > e-mail with „mvn commons-release:vote-txt“ as recommended. What is wrong with > this procedure? It's not the procedure. I simply stress FTR that the release notes become less and less what they should be, that is a summary for human consumption that attracts the user's attention on functional changes. [The full set of changes is always accessible through the commits log.] To ensure clarity for users, changes that cannot affect them should not be listed in "changes.xml". > > > Is the Log4j2 version update related to the latest security issue? > > If so, that may have been important to note. > Actually, no. log4j is an optional dependency. > > > Nit-pick: Rather than tagging them with "IMPORTANT CHANGE", it would > > be clearer that important changes are mentioned in the description, at the > > top of the release notes. > This *is* part of the description. You cannot tag changes in changes.xml. I > remember discussions about making releasing easier. Every *manual* step such > as writing release notes does not follow this direction, IMO. My opinion is that the release notes are essentially a "manual" step (even though we get help from a tool that formats the contents of "changes.xml") in the sense that the developers "talk" to the users and tell them why they should upgrade. So I think that important changes should be mentioned, if just with a sentence like "There are important changes, please read through the list below" (and that's why the list should not be cluttered with trivial changes). > > > There are a few changes marked incompatible. Is it expected in a minor > > release? > The japicmp report recommends a 0.1.0 release which it is. I don't understand why, but OK then... > > >>> [ ] +1 Release these artifacts > >>> [ ] +0 OK, but... > >>> [ ] -0 OK, but really should fix... > >>> [ ] -1 I oppose this release because… > > Would you please consider voting? +1 [There are no technical issues, only communication issues that are common problems with all the releases.] Best regards, Gilles > > Bye, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons JCS 3.1 based on rc2
Hi Gilles, > Am 14.01.2022 um 15:37 schrieb Gilles Sadowski : > >>> Maven artifacts are here: >>> >>> https://repository.apache.org/content/repositories/orgapachecommons-1576/org/apache/commons/commons-jcs3/3.1/ > > I only see one ".pom" file and one ".xml" file (with their respective > crypto sig). > … and modules below https://repository.apache.org/content/repositories/orgapachecommons-1576/org/apache/commons/commons-jcs3 > We should note that this command requires the environment variable > JAVA_HOME > to be set (otherwise the build will fail). > Is this a special requirement of this build? If so, why? > Shall we stop cluttering what should be a summary of important changes, > easily readable by a human, with bot-generated messages and trivial > one-liners like "isEmpty()"? > I followed the directions for the release preparation at https://commons.apache.org/releases/prepare.html and generated the release notes with „mvn changes:announcement-generate -Prelease-notes“ and the vote e-mail with „mvn commons-release:vote-txt“ as recommended. What is wrong with this procedure? > Is the Log4j2 version update related to the latest security issue? > If so, that may have been important to note. Actually, no. log4j is an optional dependency. > Nit-pick: Rather than tagging them with "IMPORTANT CHANGE", it would > be clearer that important changes are mentioned in the description, at the > top of the release notes. This *is* part of the description. You cannot tag changes in changes.xml. I remember discussions about making releasing easier. Every *manual* step such as writing release notes does not follow this direction, IMO. > There are a few changes marked incompatible. Is it expected in a minor > release? The japicmp report recommends a 0.1.0 release which it is. >>> [ ] +1 Release these artifacts >>> [ ] +0 OK, but... >>> [ ] -0 OK, but really should fix... >>> [ ] -1 I oppose this release because… Would you please consider voting? Bye, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
