Re: [MATH] Build Failure
Hi. Le mer. 22 déc. 2021 à 17:31, Gilles Sadowski a écrit : > > Hello. > > Le mer. 22 déc. 2021 à 15:05, Avijit Basak a écrit : > > > > Hi All > > > > I am facing a build issue for PR #199 in commons-math library. After you fix the build (cf. below), I'll create a branch dedicated to GA development, in order to clarify the issues we've been discussing. Regards, Gilles > > Next time, please provide a direct link to the build log. Thanks. > > The last Travis build is here: > https://app.travis-ci.com/github/apache/commons-math/builds/240925186 > > AFAICT, the complaints are (starting at line 8044): > ---CUT--- > [WARNING] Rule violated for bundle commons-math4-core > ---CUT--- > > However, there is no "commons-math4-core" in the "master" branch: >https://github.com/apache/commons-math/ > > Regards, > Gilles > > > The > > report summary is given below. Can anyone kindly look into the issue and do > > the needful. > > > > [ [1;34mINFO [m] Apache Commons Math > > [1;32mSUCCESS [m [ 8.501 s]*[ [1;34mINFO [m] Miscellaneous core > > classes . [1;31mFAILURE [m [ 24.551 s]* > > [ [1;34mINFO [m] Artificial neural networks . > > [1;33mSKIPPED [m > > [ [1;34mINFO [m] Transforms . > > [1;33mSKIPPED [m > > [ [1;34mINFO [m] Exception classes (Legacy) . > > [1;33mSKIPPED [m > > [ [1;34mINFO [m] Miscellaneous core classes (Legacy) > > [1;33mSKIPPED [m > > [ [1;34mINFO [m] Apache Commons Math (Legacy) ... > > [1;33mSKIPPED [m > > [ [1;34mINFO [m] Example applications ... > > [1;33mSKIPPED [m > > [ [1;34mINFO [m] SOFM ... > > [1;33mSKIPPED [m > > [ [1;34mINFO [m] Chinese Rings .. > > [1;33mSKIPPED [m > > [ [1;34mINFO [m] Traveling Salesman Problem . > > [1;33mSKIPPED [m > > [ [1;34mINFO [m] genetic algorithm .. > > [1;33mSKIPPED [m > > [ [1;34mINFO [m] examples-genetic-algorithm . > > [1;33mSKIPPED [m > > [ [1;34mINFO [m] examples-ga-math-functions . > > [1;33mSKIPPED [m > > [ [1;34mINFO [m] examples-ga-tsp > > [1;33mSKIPPED [m > > > > > > Thanks & Regards > > -- Avijit Basak - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [MATH][GENETICS][PR-199] Decision on use and customization of RNG functionality for randomization
Hi All Please see my comments below. >As I've already indicated, "ThreadLocalRandomSource" is, IMHO, a >sort of workaround for a multi-thread application that does not want >to bother managing per-thread RNG instance(s). -- I am not clear on this. ThreadLocalRandomSource maintains an EnumMap>. What is meant by it "does not want to bother managing per-thread RNG instance(s)" Could you please elaborate more on this. If this is an issue in RNG why don't we think of fixing the same or providing a different internal implementation. >The library should not make that decision for the application since we >can care for both usages: Every piece of the GA that needs a RNG can >provide factory methods that either take a "RandomSource" argument >or create a default one. -- Library can always use a default option or provide an option for customization at a global level but it need not be at the operator level(IMHO). I don't see much use of it. > > >> >2. Less/no flexibility (no user's choice of random source). > >> -- Agreed. > -- Do we really need this much flexibility here? >My main concern is that IMO the RNG is a prominent part of a GA >and it is not a good design to use "ThreadLocalRandomSource". -- RNG is definitely a prominent part. However, if we have a sharing issue with ThreadLocalRandomSource we need to think of it's alternate implementation. >How many is "too many instances"? >The memory used by an operator is tiny compared to a chromosome, >even less to a population of chromosome, or two populations of them >(parents and offsprings). --My concern is we are trying to provide a fix for a performance problem in another library and that is going to consume additional memory. > So I think we have a design tradeoff here performance vs memory > consumption. I am more worried about memory as that might restrict use of > this library beyond a certain number of dimensions in some areas. >I'm referring to separate copies for each thread. >How many threads/virtual CPUs are common nowadays? >> However, >> creating deep copy would only be possible when we strictly restrict >> extension of operators which I want to avoid. >How to avoid deep copies in a multi-thread library? >Through synchronization? -- The operator interfaces are designed like a functional interface. Accordingly, the current implementation of all operators are read only. The implementation does not maintain any mutable properties during computations too. So they are perfectly suitable for multi-threaded operation. If you see any deviation to it please notify me. > > >> So even if we provide > >> the customization at the operator level we cannot avoid sharing. > > >We can, and we should. > >What we probably can't avoid sharing is the instance that represents the > >population of chromosomes. > *--* In a multi-threaded optimization the chromosome instances are shared > in case the same chromosome is chosen for crossover by the selection > process. I missed this point earlier. > ... Chromosomes can be shared (if they are read-only). --They are read-only. > > >> > Mine is against using "ThreadLocalRandomSource"... > >> -- What is the wayout other than that. Please suggest. > > >I think I did. > *--* The factory based approach would be useful only when we can have > separate copies of operators for each set of operations. If we don't have separate copies in each thread, then the operator will not be multithreaded... -- If operators do not contain any mutable property then they are perfectly usable in a multi-threaded environment. > *--* I think we should not block the extension. >This would be going backwards to many things that have been done >to improve the robustness and reduce the bug counts of the Commons >Math codes. -- GA is different from other math functions. We may not impose the same principle on everything. > >Initially we discussed about having a light-weight library, for easier > usage > >than alternative existing framework(s). > *--* We can always think of making the framework lightweight but it should > not cost extensibility. >There is no cost: We'll gladly merge every worthy extension into >the Commons component. -- I think we have a disconnect here. If the framework is not extensible how anyone would be able to use it in any new domain. Do you mean first the framework should be changed for any new domain and users should only use it out of box. > > >> E.g. any developer should be able to extend the > >> IntegralChromosome class and define a child class which explicitly > >> specifies the range of integers to be used. > > >It does not look like this would need an extension, only configuration > >of the range. > *-- *I agree. But the question is should we block the extension. >Please find a valid use case. ;-) -- Recently I did an implementation of scheduling with commons-math 3.6. I have implemented the chromosome representing schedule by extending AbstractListChromosome. The mutation was also customized accor
Re: [MATH][GENETICS][PR-199] Decision on use and customization of RNG functionality for randomization
Hello. Le jeu. 23 déc. 2021 à 14:22, Avijit Basak a écrit : > > Hi All > > Please see my comments below. > > >As I've already indicated, "ThreadLocalRandomSource" is, IMHO, a > >sort of workaround for a multi-thread application that does not want > >to bother managing per-thread RNG instance(s). > -- I am not clear on this. ThreadLocalRandomSource maintains > an EnumMap>. What is meant > by it "does not want to bother managing per-thread RNG instance(s)" Could > you please elaborate more on this. If this is an issue in RNG why don't we > think of fixing the same or providing a different internal implementation. There is no issue in "Commons RNG"; it provides a tool. I think that it is not the right tool for a multi-threaded GA library. > > >The library should not make that decision for the application since we > >can care for both usages: Every piece of the GA that needs a RNG can > >provide factory methods that either take a "RandomSource" argument > >or create a default one. > -- Library can always use a default option or provide an option for > customization at a global level but it need not be at the operator > level(IMHO). How can a GA operator work without a RNG? It can't; it is one of the main settings of such an operator, and the reason it should be customizable. > I don't see much use of it. That's OK; that's why I proposed for this kind a use a way to generate a default instance, without any burden for the caller. > > > > >> >2. Less/no flexibility (no user's choice of random source). > > >> -- Agreed. > > -- Do we really need this much flexibility here? > > >My main concern is that IMO the RNG is a prominent part of a GA > >and it is not a good design to use "ThreadLocalRandomSource". > -- RNG is definitely a prominent part. However, if we have a sharing issue > with ThreadLocalRandomSource we need to think of it's alternate > implementation. There is a misunderstanding; there is no sharing issue, there is a design issue. > >How many is "too many instances"? > >The memory used by an operator is tiny compared to a chromosome, > >even less to a population of chromosome, or two populations of them > >(parents and offsprings). > --My concern is we are trying to provide a fix for a performance problem in > another library and that is going to consume additional memory. Nothing (at all) that we should be worried (and discussing further): Most RNG implementations are quite lean (a few hundred bytes to a few KB). You multiply this by the number of threads (a few tens at most), and you are well below 1 MB. What is this amount when compared to the average Java application nowadays? > > So I think we have a design tradeoff here performance vs memory > > consumption. I am more worried about memory as that might restrict use of > > this library beyond a certain number of dimensions in some areas. > > >I'm referring to separate copies for each thread. > >How many threads/virtual CPUs are common nowadays? > >> However, > >> creating deep copy would only be possible when we strictly restrict > >> extension of operators which I want to avoid. > > >How to avoid deep copies in a multi-thread library? > >Through synchronization? > -- The operator interfaces are designed like a functional interface. > Accordingly, the current implementation of all operators are read only. The > implementation does not maintain any mutable properties during computations > too. So they are perfectly suitable for multi-threaded operation. Great! > If you > see any deviation to it please notify me. Sure. Sorry I did not have the time to look into the code yet. > > > > >> So even if we provide > > >> the customization at the operator level we cannot avoid sharing. > > > > >We can, and we should. > > >What we probably can't avoid sharing is the instance that represents the > > >population of chromosomes. > > *--* In a multi-threaded optimization the chromosome instances are shared > > in case the same chromosome is chosen for crossover by the selection > > process. I missed this point earlier. > > ... > > Chromosomes can be shared (if they are read-only). > --They are read-only. And immutable? > > > > >> > Mine is against using "ThreadLocalRandomSource"... > > >> -- What is the wayout other than that. Please suggest. > > > > >I think I did. > > *--* The factory based approach would be useful only when we can have > > separate copies of operators for each set of operations. > > If we don't have separate copies in each thread, then the operator > will not be multithreaded... > -- If operators do not contain any mutable property then they are perfectly > usable in a multi-threaded environment. The problem is that they do: by necessity, the RNG instance is mutable. You want to hide this fact through using "ThreadLocalRandomSource", and I think that it should not be hidden. > > *--* I think we should not block the extension. > > >This would be going backwards to many things that have been done > >to improve
[VOTE] Release Apache Commons JCS 3.1 based on RC1
Hi folks, We have fixed quite a few bugs and added some significant enhancements since Apache Commons JCS 3.0 was released, so I would like to release Apache Commons JCS 3.1. Apache Commons JCS 3.1 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/jcs/COMMONS_JCS_3_1_RC1 The Git tag commons-jcs-3.1-rc1 commit for this RC is f370adb43aeef51a5456d93f13f2601f3b87c44a which you can browse here: https://gitbox.apache.org/repos/asf?p=commons-jcs.git;a=commit;h=f370adb43aeef51a5456d93f13f2601f3b87c44a You may checkout this tag using: git clone https://gitbox.apache.org/repos/asf/commons-jcs.git --branch commons-jcs-3.1-rc1 commons-jcs-3.1-rc1 Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1575/org/apache/commons/commons-jcs3/3.1/ These are the distribution artifacts and their hashes: commons-jcs3-dist-3.1-bin.tar.gz 651d9adaa7495a5411baf2903f57e1471633ba1742ce4739dd5060f186ddecfb44afe9b528eac1d904ebc8bfe43654a455fe8a6ccb0a46449acf2830ad3a015e commons-jcs3-dist-3.1-bin.zip 5e53f4ddca4071aa9d13d88b17444afdcb71f513ab0cef1be4e5dd5162c477d101b50dbecb5a7624546fbd4985d1ca4024ab6f3ef1b06d6f0a3fbfea393ba861 commons-jcs3-dist-3.1-src.tar.gz 137639d251a52ebf61b15eb710b201c2d6f1b111c507596bd49ecee313ec1e51fd885ad869addebb337cceddb1eb9ab9e73e77baf705a7cbfaae3d9bd4251ec5 commons-jcs3-dist-3.1-src.zip 013f85fa8f291b4ea3f2b43858dd48bd3335a4092339971c8a6b16751ae7c539b031ac27897d800ee2e523d3e9edf776b7a8911a9adf8633e064b489ff8de2b9 I have tested this with ***'mvn clean install site'*** using: --- Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537) Java version: 1.8.0_241, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk1.8.0_241.jdk/Contents/Home/jre Default locale: de_DE, platform encoding: UTF-8 OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac" --- Details of changes since 3.0 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/jcs/COMMONS_JCS_3_1_RC1/RELEASE-NOTES.txt https://dist.apache.org/repos/dist/dev/commons/jcs/COMMONS_JCS_3_1_RC1/site/changes-report.html Site: https://dist.apache.org/repos/dist/dev/commons/jcs/COMMONS_JCS_3_1_RC1/site/index.html (note some *relative* links are broken and the 3.1 directories are not yet created - these will be OK once the site is deployed.) JApiCmp Report (compared to 3.0): https://dist.apache.org/repos/dist/dev/commons/jcs/COMMONS_JCS_3_1_RC1/site/commons-jcs3-core/japicmp.html RAT Report: https://dist.apache.org/repos/dist/dev/commons/jcs/COMMONS_JCS_3_1_RC1/site/commons-jcs3-core/rat-report.html KEYS: https://www.apache.org/dist/commons/KEYS Please review the release candidate and vote. This vote will close no sooner that 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, Thomas Vandahl (tv), Release Manager (using key 88817402) - 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 RC1
git clone https://gitbox.apache.org/repos/asf/commons-jcs.git --branch commons-jcs-3.1-rc1 commons-jcs-3.1-rc1 Cloning into 'commons-jcs-3.1-rc1'... fatal: Remote branch commons-jcs-3.1-rc1 not found in upstream origin ? Gary On Thu, Dec 23, 2021 at 1:21 PM Thomas Vandahl wrote: > Hi folks, > > We have fixed quite a few bugs and added some significant enhancements > since Apache Commons JCS 3.0 was released, so I would like to release > Apache Commons JCS 3.1. > > Apache Commons JCS 3.1 RC1 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/jcs/COMMONS_JCS_3_1_RC1 > > The Git tag commons-jcs-3.1-rc1 commit for this RC is > f370adb43aeef51a5456d93f13f2601f3b87c44a which you can browse here: > > https://gitbox.apache.org/repos/asf?p=commons-jcs.git;a=commit;h=f370adb43aeef51a5456d93f13f2601f3b87c44a > > You may checkout this tag using: > git clone https://gitbox.apache.org/repos/asf/commons-jcs.git > --branch commons-jcs-3.1-rc1 commons-jcs-3.1-rc1 > > Maven artifacts are here: > > https://repository.apache.org/content/repositories/orgapachecommons-1575/org/apache/commons/commons-jcs3/3.1/ > > These are the distribution artifacts and their hashes: > > commons-jcs3-dist-3.1-bin.tar.gz > > 651d9adaa7495a5411baf2903f57e1471633ba1742ce4739dd5060f186ddecfb44afe9b528eac1d904ebc8bfe43654a455fe8a6ccb0a46449acf2830ad3a015e > commons-jcs3-dist-3.1-bin.zip > > 5e53f4ddca4071aa9d13d88b17444afdcb71f513ab0cef1be4e5dd5162c477d101b50dbecb5a7624546fbd4985d1ca4024ab6f3ef1b06d6f0a3fbfea393ba861 > commons-jcs3-dist-3.1-src.tar.gz > > 137639d251a52ebf61b15eb710b201c2d6f1b111c507596bd49ecee313ec1e51fd885ad869addebb337cceddb1eb9ab9e73e77baf705a7cbfaae3d9bd4251ec5 > commons-jcs3-dist-3.1-src.zip > > 013f85fa8f291b4ea3f2b43858dd48bd3335a4092339971c8a6b16751ae7c539b031ac27897d800ee2e523d3e9edf776b7a8911a9adf8633e064b489ff8de2b9 > > I have tested this with ***'mvn clean install site'*** using: > --- > Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537) > Java version: 1.8.0_241, vendor: Oracle Corporation, runtime: > /Library/Java/JavaVirtualMachines/jdk1.8.0_241.jdk/Contents/Home/jre > Default locale: de_DE, platform encoding: UTF-8 > OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac" > --- > > Details of changes since 3.0 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/jcs/COMMONS_JCS_3_1_RC1/RELEASE-NOTES.txt > > https://dist.apache.org/repos/dist/dev/commons/jcs/COMMONS_JCS_3_1_RC1/site/changes-report.html > > Site: > > https://dist.apache.org/repos/dist/dev/commons/jcs/COMMONS_JCS_3_1_RC1/site/index.html > (note some *relative* links are broken and the 3.1 directories are not > yet created - these will be OK once the site is deployed.) > > JApiCmp Report (compared to 3.0): > > https://dist.apache.org/repos/dist/dev/commons/jcs/COMMONS_JCS_3_1_RC1/site/commons-jcs3-core/japicmp.html > > RAT Report: > > https://dist.apache.org/repos/dist/dev/commons/jcs/COMMONS_JCS_3_1_RC1/site/commons-jcs3-core/rat-report.html > > KEYS: > https://www.apache.org/dist/commons/KEYS > > Please review the release candidate and vote. > This vote will close no sooner that 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, > > Thomas Vandahl (tv), > Release Manager (using key 88817402) > > > - > 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 RC1
Misses a 3 after "jcs" in branch name I think Le jeu. 23 déc. 2021 à 20:05, Gary Gregory a écrit : > git clone https://gitbox.apache.org/repos/asf/commons-jcs.git --branch > commons-jcs-3.1-rc1 commons-jcs-3.1-rc1 > Cloning into 'commons-jcs-3.1-rc1'... > fatal: Remote branch commons-jcs-3.1-rc1 not found in upstream origin > > ? > > Gary > > On Thu, Dec 23, 2021 at 1:21 PM Thomas Vandahl wrote: > > > Hi folks, > > > > We have fixed quite a few bugs and added some significant enhancements > > since Apache Commons JCS 3.0 was released, so I would like to release > > Apache Commons JCS 3.1. > > > > Apache Commons JCS 3.1 RC1 is available for review here: > > > https://dist.apache.org/repos/dist/dev/commons/jcs/COMMONS_JCS_3_1_RC1 > > > > The Git tag commons-jcs-3.1-rc1 commit for this RC is > > f370adb43aeef51a5456d93f13f2601f3b87c44a which you can browse here: > > > > > https://gitbox.apache.org/repos/asf?p=commons-jcs.git;a=commit;h=f370adb43aeef51a5456d93f13f2601f3b87c44a > > > > You may checkout this tag using: > > git clone https://gitbox.apache.org/repos/asf/commons-jcs.git > > --branch commons-jcs-3.1-rc1 commons-jcs-3.1-rc1 > > > > Maven artifacts are here: > > > > > https://repository.apache.org/content/repositories/orgapachecommons-1575/org/apache/commons/commons-jcs3/3.1/ > > > > These are the distribution artifacts and their hashes: > > > > commons-jcs3-dist-3.1-bin.tar.gz > > > > > 651d9adaa7495a5411baf2903f57e1471633ba1742ce4739dd5060f186ddecfb44afe9b528eac1d904ebc8bfe43654a455fe8a6ccb0a46449acf2830ad3a015e > > commons-jcs3-dist-3.1-bin.zip > > > > > 5e53f4ddca4071aa9d13d88b17444afdcb71f513ab0cef1be4e5dd5162c477d101b50dbecb5a7624546fbd4985d1ca4024ab6f3ef1b06d6f0a3fbfea393ba861 > > commons-jcs3-dist-3.1-src.tar.gz > > > > > 137639d251a52ebf61b15eb710b201c2d6f1b111c507596bd49ecee313ec1e51fd885ad869addebb337cceddb1eb9ab9e73e77baf705a7cbfaae3d9bd4251ec5 > > commons-jcs3-dist-3.1-src.zip > > > > > 013f85fa8f291b4ea3f2b43858dd48bd3335a4092339971c8a6b16751ae7c539b031ac27897d800ee2e523d3e9edf776b7a8911a9adf8633e064b489ff8de2b9 > > > > I have tested this with ***'mvn clean install site'*** using: > > --- > > Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537) > > Java version: 1.8.0_241, vendor: Oracle Corporation, runtime: > > /Library/Java/JavaVirtualMachines/jdk1.8.0_241.jdk/Contents/Home/jre > > Default locale: de_DE, platform encoding: UTF-8 > > OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac" > > --- > > > > Details of changes since 3.0 are in the release notes: > > > > > https://dist.apache.org/repos/dist/dev/commons/jcs/COMMONS_JCS_3_1_RC1/RELEASE-NOTES.txt > > > > > https://dist.apache.org/repos/dist/dev/commons/jcs/COMMONS_JCS_3_1_RC1/site/changes-report.html > > > > Site: > > > > > https://dist.apache.org/repos/dist/dev/commons/jcs/COMMONS_JCS_3_1_RC1/site/index.html > > (note some *relative* links are broken and the 3.1 directories are > not > > yet created - these will be OK once the site is deployed.) > > > > JApiCmp Report (compared to 3.0): > > > > > https://dist.apache.org/repos/dist/dev/commons/jcs/COMMONS_JCS_3_1_RC1/site/commons-jcs3-core/japicmp.html > > > > RAT Report: > > > > > https://dist.apache.org/repos/dist/dev/commons/jcs/COMMONS_JCS_3_1_RC1/site/commons-jcs3-core/rat-report.html > > > > KEYS: > > https://www.apache.org/dist/commons/KEYS > > > > Please review the release candidate and vote. > > This vote will close no sooner that 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, > > > > Thomas Vandahl (tv), > > Release Manager (using key 88817402) > > > > > > - > > 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 RC1
Yeah, sorry - typo. > Am 23.12.2021 um 19:20 schrieb Thomas Vandahl : > > The Git tag commons-jcs3-3.1-rc1 commit for this RC is > f370adb43aeef51a5456d93f13f2601f3b87c44a which you can browse here: > > https://gitbox.apache.org/repos/asf?p=commons-jcs.git;a=commit;h=f370adb43aeef51a5456d93f13f2601f3b87c44a > > You may checkout this tag using: >git clone https://gitbox.apache.org/repos/asf/commons-jcs.git --branch > commons-jcs3-3.1-rc1 commons-jcs3-3.1-rc1 Sorry for the confusion. 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 RC1
My vote: > Am 23.12.2021 um 19:20 schrieb Thomas Vandahl : > > [X] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... 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 RC1
+1 as well (tested on some apps and checked source bundle) Le jeu. 23 déc. 2021 à 20:42, Thomas Vandahl a écrit : > My vote: > > > Am 23.12.2021 um 19:20 schrieb Thomas Vandahl : > > > > [X] +1 Release these artifacts > > [ ] +0 OK, but... > > [ ] -0 OK, but really should fix... > > [ ] -1 I oppose this release because... > > 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 RC1
Hi, I couldn't find the tag "commons-jcs-3.1-rc1", I think the tag is "commons-jcs3-3.1-rc1" (missing 3 after jcs)? Building from that tag on: Apache Maven 3.8.2 (ea98e05a04480131370aa0c110b8c54cf726c06f) Maven home: /opt/apache-maven-3.8.2 Java version: 11.0.13, vendor: Ubuntu, runtime: /usr/lib/jvm/java-11-openjdk-amd64 Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "5.4.0-91-generic", arch: "amd64", family: "unix" with `mvn clean test install site` had one test failing: [INFO] [ERROR] Failures: [ERROR] SerializerUnitTest.testReadWrite:116 [key:0] should not be null, Region Name = blockRegion2 HitCountRam = 0 HitCountAux = 0 ---Memory Cache Put Count = 0 Hit Count = 0 Miss Count = 1 Map Size = 0 List Size = 0 ---Block Disk Cache Is Alive = true Key Map Size = 0 Data File Length = 0 Block Size Bytes = 4096 Number Of Blocks = 0 Average Put Size Bytes = 0 Empty Blocks = 0 Purgatory Hits = 0 Purgatory Size = 0 Working = true Empty = true Queue Size = 0 Queue Capacity = 2147483647 [INFO] [ERROR] Tests run: 419, Failures: 1, Errors: 0, Skipped: 0 [INFO] [INFO] [INFO] Reactor Summary for Apache Commons JCS 3.1: [INFO] [INFO] Apache Commons JCS . SUCCESS [03:34 min] [INFO] Apache Commons JCS :: Core . FAILURE [ 01:43 h] [INFO] Apache Commons JCS :: JCache ... SKIPPED [INFO] Apache Commons JCS :: JCache TCK ... SKIPPED [INFO] Apache Commons JCS :: JCache Extras SKIPPED [INFO] Apache Commons JCS :: JCache OpenJPA ... SKIPPED [INFO] Apache Commons JCS :: Distribution . SKIPPED [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 01:46 h [INFO] Finished at: 2021-12-24T13:12:42+13:00 [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on project commons-jcs3-core: There are test failures. Bruno On Friday, 24 December 2021, 07:21:08 am NZDT, Thomas Vandahl wrote: Hi folks, We have fixed quite a few bugs and added some significant enhancements since Apache Commons JCS 3.0 was released, so I would like to release Apache Commons JCS 3.1. Apache Commons JCS 3.1 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/jcs/COMMONS_JCS_3_1_RC1 The Git tag commons-jcs-3.1-rc1 commit for this RC is f370adb43aeef51a5456d93f13f2601f3b87c44a which you can browse here: https://gitbox.apache.org/repos/asf?p=commons-jcs.git;a=commit;h=f370adb43aeef51a5456d93f13f2601f3b87c44a You may checkout this tag using: git clone https://gitbox.apache.org/repos/asf/commons-jcs.git --branch commons-jcs-3.1-rc1 commons-jcs-3.1-rc1 Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1575/org/apache/commons/commons-jcs3/3.1/ These are the distribution artifacts and their hashes: commons-jcs3-dist-3.1-bin.tar.gz 651d9adaa7495a5411baf2903f57e1471633ba1742ce4739dd5060f186ddecfb44afe9b528eac1d904ebc8bfe43654a455fe8a6ccb0a46449acf2830ad3a015e commons-jcs3-dist-3.1-bin.zip 5e53f4ddca4071aa9d13d88b17444afdcb71f513ab0cef1be4e5dd5162c477d101b50dbecb5a7624546fbd4985d1ca4024ab6f3ef1b06d6f0a3fbfea393ba861 commons-jcs3-dist-3.1-src.tar.gz 137639d251a52ebf61b15eb710b201c2d6f1b111c507596bd49ecee313ec1e51fd885ad869addebb337cceddb1eb9ab9e73e77baf705a7cbfaae3d9bd4251ec5 commons-jcs3-dist-3.1-src.zip 013f85fa8f291b4ea3f2b43858dd48bd3335a4092339971c8a6b16751ae7c539b031ac27897d800ee2e523d3e9edf776b7a8911a9adf8633e064b489ff8de2b9 I have tested this with ***'mvn clean install site'*** using: --- Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537) Java version: 1.8.0_241, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk1.8.0_241.jdk/Contents/Home/jre Default locale: de_DE, platform encoding: UTF-8 OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac" --- Details of changes since 3.0 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/jcs/COMMONS_JCS_3_1_RC1/RELEASE-NOTES.txt https://dist.apache.org/repos/dist/dev/commons/jcs/COMMONS_JCS_3_1_RC1/site/changes-report.html Site: https://dist.apache.org/repos/dist/dev/commons/jcs/COMMONS_JCS_3_1_RC1/site/index.html (note some *relative* links are broken and the 3.1 directories are not yet created - these will be OK once the site is deployed.) JApiCmp Report (compared to 3.0): https://dist.apache.org/repos/dist/dev/commons/jcs/COMMONS_JCS_3_1_RC1/site/commons-jcs3-core/japicmp.html RAT Report: https://dist.apache.org/repos/dist/dev/
