Re: [VOTE] Release Apache Commons Text 1.9 based on RC1
+1 Release this artifact. build, tests passing well, everything from defaultGoal looks good to me. the site, hashes look good. Regards, Amey --- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org On Wed, Jul 22, 2020 at 2:27 AM Gary Gregory wrote: > Hi All, > > We have fixed a few bugs and added some enhancements since Apache Commons > Text 1.8 was released, so I would like to release Apache Commons Text 1.9. > > Apache Commons Text 1.9 RC1 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/text/1.9-RC1 (svn > revision 40617) > > The Git tag commons-text-1.9-RC1 commit for this RC is > cb85bed468e99d34b88d0c81fe20eb3b1615660e which you can browse here: > > > https://gitbox.apache.org/repos/asf?p=commons-text.git;a=commit;h=cb85bed468e99d34b88d0c81fe20eb3b1615660e > You may checkout this tag using: > git clone https://gitbox.apache.org/repos/asf/commons-text.git > --branch > commons-text-1.9-RC1 commons-text-1.9-RC1 > > Maven artifacts are here: > > > https://repository.apache.org/content/repositories/orgapachecommons-1508/org/apache/commons/commons-text/1.9/ > > These are the artifacts and their hashes: > > #Release SHA-512s > #Tue Jul 21 16:40:42 EDT 2020 > > commons-text-1.9-bin.tar.gz=02d4f9bc28aad82c461c5e9b1ceeaa3e8f4ece93e70918f79c090f6e2e5d8b4053944b67f70c4db7e2bb3311194484916440e030aea13f8b2fa76416b052740a > > commons-text-1.9-bin.zip=2a6873186e69271edf038b6dfb986fee80970f32dd71a587578b1964e9c3ebdd38645fdd1c3b82b27a9235695ed3a8bf7206e996414417740110507078e67392 > > commons-text-1.9-javadoc.jar=ee587b5994bd3b0fdb5d3ba322e9a76ca427476a9480fab769c0f3b6145843fa672b89d8fd8498a809a65a1c802e585a75ca91bccc82fc30aa658bc71042e5a6 > > commons-text-1.9-sources.jar=9f09fae39b37a18101754ee65ba13e53909337644cacfbc4a86798b3fb1e23317c2c849a9975b077e72fa2f91f8af30c6ac10664ec11d6107a225b445cc93ae7 > > commons-text-1.9-src.tar.gz=53f993e79aaa6789d3388aa96b6b2a14cf646b27ff3774524390e511241a85288947cc929519eff61a8734578f25bdf3d9969d84da20c1a749b19d90a55da8ae > > commons-text-1.9-src.zip=455f3f1552d2b88496c5e9dee0a39f7bd42ff413e9b055eae5c6cc9bb122a55bfe3de7481acce5406fe0aef247b78d1a9f90a0a43ba69f7f7288610323aa742f > > commons-text-1.9-test-sources.jar=0ca935e0c3326bbc2627f9e2099fb1950643882ef268c14513f1fac46e8e779d3904f70c7eca20c9e905876efd18a1b1a6b747fc6375fcb15231149ac0371de6 > > commons-text-1.9-tests.jar=295a36064cdce3b2f7b6c51d19c2391ec53456019ac4a16f76085cd69f39958e7becc8ede3b6391d7bf19ec53afb513f13db884ac152f8749247d1df973ff75e > > I have tested this with > > mvn -V -Duser.name=%my_apache_id% > -Dcommons.release-plugin.version=%commons.release-plugin.version% -Prelease > -Ptest-deploy -P jacoco -P japicmp clean package site deploy > > using: > > Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) > Maven home: C:\Java\apache-maven-3.6.3\bin\.. > Java version: 1.8.0_251, vendor: Oracle Corporation, runtime: C:\Program > Files\Java\jdk1.8.0_251\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > > Details of changes since 1.8 are in the release notes: > > > https://dist.apache.org/repos/dist/dev/commons/text/1.9-RC1/RELEASE-NOTES.txt > > > https://dist.apache.org/repos/dist/dev/commons/text/1.9-RC1/site/changes-report.html > > Site: > > https://dist.apache.org/repos/dist/dev/commons/text/1.9-RC1/site/index.html > (note some *relative* links are broken and the 1.9 directories are not > yet created - these will be OK once the site is deployed.) > > JApiCmp Report (compared to 1.8): > > > https://dist.apache.org/repos/dist/dev/commons/text/1.9-RC1/site/japicmp.html > > RAT Report: > > > https://dist.apache.org/repos/dist/dev/commons/text/1.9-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 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, > > Gary Gregory, > Release Manager (using key 86fdc7e2a11262cb) > > 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
Re: [Text] do we have number to word converter ?
On Wed, Jul 1, 2020 at 1:18 AM Gary Gregory wrote: > I am not sure we should have something so language dependent here. Making > it plugable feels out of scope with one resource bundle per language and so > on. Might be worth seeing how java.time deals with this kind of issue if at > all. > java.time internally uses DateTimeFormatter[1] and that internally uses Locale[2] I think we can create the Utility with default English and provision to plugin different Locale. [1] https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html [2]https://docs.oracle.com/javase/8/docs/api/java/util/Locale.html Regards, Amey > > > Gary > > On Tue, Jun 30, 2020, 14:47 Jason Pyeron wrote: > > > > -Original Message- > > > From: Amey Jadiye Sent: Tuesday, June 30, 2020 2:04 PM > > > > > > Hi, > > > > > > Does anyone know if apache commons have any utility which converts > number > > > to words ? > > > > > > Ex. 3957 = Three Thousand Nine Hundred and fifty seven. > > > > If not, can dig up the one we made for united states (English) checks and > > donate it to Apache. > > > > > > > > - > > 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
[Text] do we have number to word converter ?
Hi, Does anyone know if apache commons have any utility which converts number to words ? Ex. 3957 = Three Thousand Nine Hundred and fifty seven. Regards, Amey
Re: [LAZY][VOTE] Commons Parent POM 51 based on RC2
+1 Build and basic verifications look good. Installed from src locally. Tested on commons-text, commons-graph (forked repo). used LTS for testing. everything works fine. mvn -Duser.name=ameyjadiye -Dcommons.release.dryRun=true -Ptest-deploy clean verify package site deploy apache-rat:check clirr:check checkstyle:check spotbugs:check javadoc:javadoc Regards, Amey On Thu, Jun 18, 2020 at 10:26 PM sebb wrote: > The Apache Commons Parent POM provides common settings for all Apache > Commons components. > > > This is a VOTE to release Commons Parent 51 based on RC2 > > > This VOTE by LAZY-CONSENSUS is open for at least 72 hours > It will close not before June 21 17:00 UTC > > > Fix incompatibilty issues with Java 7 > Add support for Java 13. > Update various plugin versions. > > Changes in this version include: > > New features: > o Allow override of changes.announcementFile/announcementDirectory > > Fixed Bugs: > o Allow Java7 builds: commons.animal-sniffer.version=1.17; > biz.aQute.bndlib.version=3.5.0 > o PR#5: change to for maven javadoc plugin. > > Changes: > o JApiCmp 0.14.1 -> 0.14.3. > o maven-enforcer-plugin 3.0.0-M2 -> 3.0.0-M3. > o maven-source-plugin 3.2.0 -> 3.2.1. > o commons.spotbugs.version 3.1.6 -> 3.1.12.2. > o org.apache:apache 21 -> 23. > o maven-javadoc-plugin 3.1.1 -> 3.2.0. > o commons.pmd.version 3.12.0 -> 3.13.0. > o Fix https://github.com/bndtools/bnd/issues/3903 seen with Commons CSV. > o commons.project-info.version 3.0.0 -> 3.1.0 > o Add support for Java 13 > o Support NOTICE and LICENSE alongside .txt versions > o commons.wagon-ssh.version 3.0.0 -> 3.1.0 > o biz.aQute.bndlib.version 5.0.1 => 5.1.0 > o bcel version 6.4.1 => 6.5.0 > o maven pre-requisite 3.0.5 => 3.5.0 > o commons.build-helper.version 3.0.0 => 3.1.0 > > The files (staged): > > https://repository.apache.org/content/repositories/orgapachecommons-1501/ > > commons-parent-51.pom > SHA1: 2f1f8c26ad5602fdff6c3f95f38887943cd68470 > > commons-parent-51-site.xml > SHA1: 7d3b170166d71ffe8b006d741acc5044b6914784 > > The source archives: > https://dist.apache.org/repos/dist/dev/commons/commons-parent/51-RC2/ > (r40087) > > > 4b6e8e843a7caa5a32c337e054a57439a07e9226001c93f8d3bf4d2104f60a3e7b0a1f04704acd94f669f1fb06ef71cebc0323a48a815dbbf6b47280cb8da2af > commons-parent-51-site.xml > > b672164878c79430b2fa9aa0bf2210b57e3815d0a6351b0ce1e02d5edddf8d6415b0d6a75c4b2993d61d50df3960c8b5ffd8daa2d51b879a5bdc99f4a704e45d > commons-parent-51-src.tar.gz > > 72e5f9556feb505e4c3c51b57ab335a65c1434c2ca69bea8972f8a6a5ca3ef07834b0696bc2acc7f94a7a17d2cba30119f8df6b8576f7fc139c79b5202492ce8 > commons-parent-51-src.zip > > > The tag: > https://github.com/apache/commons-parent/tree/commons-parent-51-RC2 > 66cc783124e88562d2e28a8384f675effe791bc5 > <https://github.com/apache/commons-parent/tree/commons-parent-51-RC266cc783124e88562d2e28a8384f675effe791bc5> > > The site: None; the page http://commons.apache.org/commons-parent-pom.html > will be updated once the POM has been released > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [Graph] Build fails (unit tests)
On Sat, Jun 13, 2020 at 8:50 PM Gilles Sadowski wrote: > Hi. > > 2020-06-13 16:57 UTC+02:00, Amey Jadiye : > > Hello Gilles, > > > > On Sat, Jun 13, 2020 at 6:36 PM Gilles Sadowski > > wrote: > > > >> Hello. > >> > >> After the migration from SVN to "gitbox", we noticed that the > >> _first_ build failed due to 3 unit tests not passing (see e.g. the > >> Travis report referred to the JIRA report[1]). > >> > >> The move to "git" was intended to make it easier for people > >> willing to revive the [Graph] project. > >> > >> IMO, the top priority is now to fix the failing unit tests; > >> personally, I'm not going to merge any PR before that is > >> achieved (and please refer to the JIRA identifier[1] in the > >> corresponding commit/PR). > >> > > > > Indeed, that's what I think too. I have tried to stop bleeding > > commons-graph for now PR https://github.com/apache/commons-graph/pull/3, > > along with some more small nitty-gritty. > > > > > >> Furthermore, I'd suggest that branch "modularization" > >> becomes the reference branch (in place of "master"[2]), > >> since the latest batch of work for [Graph] was done on > >> that one, seemingly leaving "master" behind (TBC by > >> Amey?). [This path might avoid subsequent work of > >> merging the fixed (but outdated) "master" into the more > >> recent branch that is bound to replace it anyway...] > >> > > > > I am on the way to push my changes to master regarding modularization. I > > have more intention to push changes in master now. > > > > 1. I have just stopped bleeding due to failing test cases, with TODO > > marking though, so we can pull this work later once the > > "modularized" version of the comons-graph becomes stable in "master". > > Please open a JIRA report for this issue (with one sub-task > per module created, if you wish) > Upon completion please submit a single PR, with a single > commit per sub-task/module. > > Since this was a sandbox, abandoned, project, I don't care > about what, and how many, changes that will involve: I won't > have time to review them anyway. > If others have a different opinion, they should indicate their > willingness to perform more fine-grained reviews. > > If no one steps forward, then please try and follow the code > style used in "Commons RNG" (i.e. change the style of the > source code: e.g. no space after an opening parenthesis or > before a closing one, etc.). Perhaps someone can suggest > some IDE plugin that will automatically update the whole > code base... > > > > > 2. I'm comparing each and every class from master to a modularized > version > > of graph to make sure we don't miss anything behind from master. > > +1 > Thanks! > > > 3. we should not take my merge in functional code in the meantime, other > > related to Travis, Builds, Coverall is ok to accept as it > > doesn't interfere with /src. > > I didn't get what you mean. > > sorry for my English, I meant that taking chances in the current master is of no use. All addition/changes related to graph, algorithms, tests should go to a new modularized code. all the changes in /src should be stopped for now. other changes outsite /src can be merged. Regards, Amey > Regards, > Gilles > > >> > >> [1] https://issues.apache.org/jira/browse/SANDBOX-510 > >> [2] Even though the names of the maven "modules" should > >> be changed (for the sake of code layout "standardization" > >> with other modular components such as "Commons RNG"). > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [Graph] Build fails (unit tests)
On Sat, Jun 13, 2020 at 8:27 PM Amey Jadiye wrote: > Hello Gilles, > > On Sat, Jun 13, 2020 at 6:36 PM Gilles Sadowski > wrote: > >> Hello. >> >> After the migration from SVN to "gitbox", we noticed that the >> _first_ build failed due to 3 unit tests not passing (see e.g. the >> Travis report referred to the JIRA report[1]). >> >> The move to "git" was intended to make it easier for people >> willing to revive the [Graph] project. >> >> IMO, the top priority is now to fix the failing unit tests; >> personally, I'm not going to merge any PR before that is >> achieved (and please refer to the JIRA identifier[1] in the >> corresponding commit/PR). >> > > Indeed, that's what I think too. I have tried to stop bleeding > commons-graph for now PR https://github.com/apache/commons-graph/pull/3, > along with some more small nitty-gritty. > > >> Furthermore, I'd suggest that branch "modularization" >> becomes the reference branch (in place of "master"[2]), >> since the latest batch of work for [Graph] was done on >> that one, seemingly leaving "master" behind (TBC by >> Amey?). [This path might avoid subsequent work of >> merging the fixed (but outdated) "master" into the more >> recent branch that is bound to replace it anyway...] >> > > I am on the way to push my changes to master regarding modularization. I > have more intention to push changes in master now. > typo mistake, I have *no more* intension to push in master :-) > > 1. I have just stopped bleeding due to failing test cases, with TODO > marking though, so we can pull this work later once the > "modularized" version of the comons-graph becomes stable in "master". > > 2. I'm comparing each and every class from master to a modularized version > of graph to make sure we don't miss anything behind from master. > > 3. we should not take my merge in functional code in the meantime, other > related to Travis, Builds, Coverall is ok to accept as it > doesn't interfere with /src. > > Regards, > Amey > > >> >> Thanks, >> Gilles >> >> [1] https://issues.apache.org/jira/browse/SANDBOX-510 >> [2] Even though the names of the maven "modules" should >> be changed (for the sake of code layout "standardization" >> with other modular components such as "Commons RNG"). >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >>
Re: [Graph] Build fails (unit tests)
Hello Gilles, On Sat, Jun 13, 2020 at 6:36 PM Gilles Sadowski wrote: > Hello. > > After the migration from SVN to "gitbox", we noticed that the > _first_ build failed due to 3 unit tests not passing (see e.g. the > Travis report referred to the JIRA report[1]). > > The move to "git" was intended to make it easier for people > willing to revive the [Graph] project. > > IMO, the top priority is now to fix the failing unit tests; > personally, I'm not going to merge any PR before that is > achieved (and please refer to the JIRA identifier[1] in the > corresponding commit/PR). > Indeed, that's what I think too. I have tried to stop bleeding commons-graph for now PR https://github.com/apache/commons-graph/pull/3, along with some more small nitty-gritty. > Furthermore, I'd suggest that branch "modularization" > becomes the reference branch (in place of "master"[2]), > since the latest batch of work for [Graph] was done on > that one, seemingly leaving "master" behind (TBC by > Amey?). [This path might avoid subsequent work of > merging the fixed (but outdated) "master" into the more > recent branch that is bound to replace it anyway...] > I am on the way to push my changes to master regarding modularization. I have more intention to push changes in master now. 1. I have just stopped bleeding due to failing test cases, with TODO marking though, so we can pull this work later once the "modularized" version of the comons-graph becomes stable in "master". 2. I'm comparing each and every class from master to a modularized version of graph to make sure we don't miss anything behind from master. 3. we should not take my merge in functional code in the meantime, other related to Travis, Builds, Coverall is ok to accept as it doesn't interfere with /src. Regards, Amey > > Thanks, > Gilles > > [1] https://issues.apache.org/jira/browse/SANDBOX-510 > [2] Even though the names of the maven "modules" should > be changed (for the sake of code layout "standardization" > with other modular components such as "Commons RNG"). > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [commons-graph] branch master updated: Travis CI configuration.
On Fri, Jun 12, 2020 at 4:40 PM Gilles Sadowski wrote: > 2020-06-12 12:32 UTC+02:00, Xeno Amess : > > Hi. > > I see the current travis-ci scripts. > > Do we really care only jdk8? > > Should we also add at some other jdk versions, at least adding openjdk11, > > as it is a stable version? > > Or this repo has some known bug on jdk11? > > > > Before refining, we should get[1] a first build: > https://travis-ci.org/github/apache/commons-graph +1 maybe you can check and merge my one upgrade PR to check this. https://github.com/apache/commons-graph/pull/1 I don't see it on Travis though, maybe because I raised it before travis setup. Regards, Amey > > > Gilles > > [1] https://issues.apache.org/jira/browse/INFRA-20413 > > - > 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
[commons-graph] modularization [was]Re: commons-graph still on sandbox ?
On Thu, Jun 11, 2020 at 9:24 PM Gilles Sadowski wrote: > Hello Amey. > > Hello Gilles , > > I've just noticed that quite some work was done towards > that goal. I created the corresponding branch on "gitbox". > From a quick glance, the maven modules do not follow the > convention of modular components such as "Commons > RNG": a module's name should be > commons-graph-api > rather then just > api > Thanks for pushing it to git, I was aware about the modularization branch from the old svn repository, I was referring same for modularisation. > > I suggest that you take "Commons RNG" as an example, > and update [Graph] accordingly (namely the POM files). > Thanks for the reference of RNG, will certainly refer it for graph modularization. I have already started upgrading the codebase and pushing PR's. https://github.com/apache/commons-graph/pull/1 Meantime could you please set up the Travis-CI for commons-graph? I have mentioned https://travis-ci.org/apache/commons-graph in README, for now, it doesn't exist though. not sure if PMC can do this or this goes to INFRA? [Somehow the tool recommended by INFRA did not do a full > job of duplicating the code base on SVN... There are other > (older) branches there; so you might want to have a look and > let us know whether you want them on git too or whether they > are outdated.] > Just modularization brach is ok for now. Thank You! > Regards, > Gilles > > > > > > [...] > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > Regards, Amey Jadiye - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Graph] moving to git
On Mon, Jun 8, 2020 at 2:50 AM Gilles Sadowski wrote: > Hello. > > Repository available: > https://gitbox.apache.org/repos/asf?p=commons-graph.git > > Thanks Gilles. Regards, > Gilles > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons BCEL 6.5.0 based on RC1
+1 Release these artifacts Everything looks good to me. Build passing on java 8 and 11. Tests, Rat, Japicmp, checkstyle passing fine. 1. Apologies, I might have missed discussions but I don't understand reason behind @Ignore on JiraBcel291TestCase and skipping it from test suite. [INFO] Running org.apache.bcel.verifier.JiraBcel291TestCase [WARNING] Tests run: 1, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0.011 s - in org.apache.bcel.verifier.JiraBcel291TestCase 2. Javadoc is generating huge amount of warnings, as far as build and tests are passing, I'm fine with the release. Regards, Amey Jadiye On Sat, Jun 6, 2020 at 6:04 PM Gary Gregory wrote: > We have fixed a few bugs and added some enhancements since Apache Commons > BCEL 6.4.1 was released, so I would like to release Apache Commons BCEL > 6.5.0. > > Apache Commons BCEL 6.5.0 RC1 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/bcel/6.5.0-RC1 (svn > revision 39954) > > The Git tag commons-bcel-6.5.0-RC1 commit for this RC is > a9c13ede0e565fae0593c1fde3b774d93abf3f71 which you can browse here: > > > https://gitbox.apache.org/repos/asf?p=commons-bcel.git;a=commit;h=a9c13ede0e565fae0593c1fde3b774d93abf3f71 > You may checkout this tag using: > git clone https://gitbox.apache.org/repos/asf/commons-bcel.git > --branch > commons-bcel-6.5.0-RC1 commons-bcel-6.5.0-RC1 > > Maven artifacts are here: > > > https://repository.apache.org/content/repositories/orgapachecommons-1499/org/apache/bcel/bcel/6.5.0/ > > These are the artifacts and their hashes: > > #Release SHA-512s > #Fri Jun 05 17:50:12 EDT 2020 > > bcel-6.5.0-bin.tar.gz=a97eb0b8c39ec96cf15168cc38d51065d4c3223729069bdf86ace61970124d73cee4b5ccfae605d0184c3154247abd382fc59241cecafb678532237167631212 > > bcel-6.5.0-bin.zip=683f89e3c365d95882ca6d4d68408f578f25a5f5fda5af732cab175b29558b8d8c0a97aaa7d3026ba645d54160095dcda048ee12232f5a3f03e1293dd6621f20 > > bcel-6.5.0-javadoc.jar=c82e46d666b04035b313ccf99e2e513bd02740c1c90d5cf0e02e00b819382525a1a793da72f3519a706ea189d5b163c72cf4d4a2feed6b74a47d756a912e905d > > bcel-6.5.0-sources.jar=2917b32067cd8c76b1691df8e882cf10be0fe6328e366c0d335e0f5e85d861a612577b1d9fbb2e6980a8fceb618f80abf8c1c80aa350c9e4a7166d4c2fb056dd > > bcel-6.5.0-src.tar.gz=c6da4b4d4cbad3ad2b3a4c0208063e3858170356fc4f6670c95ce819f0aea69f103914875a12bf2715a869c2b19a3e79fcb55a695eb269d9937520db25da1e3d > > bcel-6.5.0-src.zip=45642eb5e93da9da7252f17a0e58ee17c952b569e86d398353daa2a0bf4846a34ea79acd3329fa317814e15706e9993d4529c217476734918b97e1adb2ea7773 > > bcel-6.5.0-test-sources.jar=aed90e44f7e49e2ea39e945a55aa2bf28b7c87685afea0c68d3e83f1acb5488290d70d2b18f62a89bf31509f226ee3c46811e608b7bca447edeceb83bdee3a4d > > bcel-6.5.0-tests.jar=2b7dfef01c8f885e351590267c5236c6512658ddb70ab80ca1fb5b9035e4176a410f76dc22199959a2343c03917fc30d1fe6d35715cc3bae550a8021f0ea7e57 > > I have tested this with 'mvn -V -Duser.name=%my_apache_id% > -Dcommons.release-plugin.version=%commons.release-plugin.version% -Prelease > -Ptest-deploy -P jacoco -P japicmp clean package site deploy' using: > > Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) > Maven home: C:\Java\apache-maven-3.6.3\bin\.. > Java version: 1.8.0_251, vendor: Oracle Corporation, runtime: C:\Program > Files\Java\jdk1.8.0_251\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > > Details of changes since 6.4.1 are in the release notes: > > > https://dist.apache.org/repos/dist/dev/commons/bcel/6.5.0-RC1/RELEASE-NOTES.txt > > > https://dist.apache.org/repos/dist/dev/commons/bcel/6.5.0-RC1/site/changes-report.html > > Site: > > > https://dist.apache.org/repos/dist/dev/commons/bcel/6.5.0-RC1/site/index.html > (note some *relative* links are broken and the 6.5.0 directories are > not yet created - these will be OK once the site is deployed.) > > JApiCmp Report (compared to 6.4.1): > > > https://dist.apache.org/repos/dist/dev/commons/bcel/6.5.0-RC1/site/japicmp.html > > RAT Report: > > > https://dist.apache.org/repos/dist/dev/commons/bcel/6.5.0-RC1/site/rat-report.html > > KEYS: > https://www.apache.org/dist/commons/KEYS > > Please review the release candidate and vote. > This vote will close no sooner 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, > > Gary Gregory, > Release Manager (using key 86fdc7e2a11262cb) > > For following is intended as a helper and refresher for reviewers. > > Validating a release candidate > ==
Re: [Graph] moving to git
On Thu, Jun 4, 2020 at 2:44 AM Gilles Sadowski wrote: > Le mer. 3 juin 2020 à 16:03, Jochen Wiedmann > a écrit : > > > > On Tue, Jun 2, 2020 at 3:30 AM Amey Jadiye wrote: > > > > > I wanted to fetch opinion about moving commons-graph to git and > possibly > > > creation of github mirror. > > > > We still haven't completed the move? > > > > Sure, as quick as possible. > > Requested: > https://issues.apache.org/jira/browse/INFRA-20381 > > Thanks much Gilles :-) > Regards, > Gilles > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Graph] moving to git
Hi All, Can we get more opinions on this? what PMC thinks on this ? I wish to get commons-graph on git at least. okey with full sandbox to git if it's easy with other operational aspects. Regards, Amey Jadiye On Tue, Jun 2, 2020, 7:09 AM Amey Jadiye wrote: > > > On Tue, Jun 2, 2020 at 8:54 AM Bruno P. Kinoshita > wrote: > >> I **think** projects using Apache gitbox can be/are hosted/mirrored on >> GitHub. >> >> As for moving to git, I'm +1 in principle. But I don't know if we create >> git repositories under github.com/apache for projects in the sandbox. >> Maybe one option here would be moving the sandbox over to git instead? >> Along with all the components there? >> >> > Moving full sandbox sounds like moving all proper to git which was never > happened, we migrated project by project. at this point I just care about > moving commons-graph to git. also if we move full sandbox to git and > tomorrow if we migrate commons-graph to proper and to its own repository, > will the git commit history for only graph be separately migrated since > sandbox is root repository ? > > >> Sorry if not very helpful. >> >> Bruno >> >> >> On Tuesday, 2 June 2020, 1:30:06 pm NZST, Amey Jadiye < >> ameyjad...@gmail.com> wrote: >> >> >> >> >> >> Hello All, >> >> I wanted to fetch opinion about moving commons-graph to git and possibly >> creation of github mirror. >> >> 1. Moving to git will be better for code management and change / >> contribution history perspective. >> >> 2. Github will be better to attract more contributors and easy to review >> codes via PR, not sure if Apache gitbox have same capabilities ? >> >> Regards, >> Amey Jadiye >> >> - >> 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: [Graph] moving to git
On Tue, Jun 2, 2020 at 8:54 AM Bruno P. Kinoshita wrote: > I **think** projects using Apache gitbox can be/are hosted/mirrored on > GitHub. > > As for moving to git, I'm +1 in principle. But I don't know if we create > git repositories under github.com/apache for projects in the sandbox. > Maybe one option here would be moving the sandbox over to git instead? > Along with all the components there? > > Moving full sandbox sounds like moving all proper to git which was never happened, we migrated project by project. at this point I just care about moving commons-graph to git. also if we move full sandbox to git and tomorrow if we migrate commons-graph to proper and to its own repository, will the git commit history for only graph be separately migrated since sandbox is root repository ? > Sorry if not very helpful. > > Bruno > > > On Tuesday, 2 June 2020, 1:30:06 pm NZST, Amey Jadiye < > ameyjad...@gmail.com> wrote: > > > > > > Hello All, > > I wanted to fetch opinion about moving commons-graph to git and possibly > creation of github mirror. > > 1. Moving to git will be better for code management and change / > contribution history perspective. > > 2. Github will be better to attract more contributors and easy to review > codes via PR, not sure if Apache gitbox have same capabilities ? > > Regards, > Amey Jadiye > > - > 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
[Graph] moving to git
Hello All, I wanted to fetch opinion about moving commons-graph to git and possibly creation of github mirror. 1. Moving to git will be better for code management and change / contribution history perspective. 2. Github will be better to attract more contributors and easy to review codes via PR, not sure if Apache gitbox have same capabilities ? Regards, Amey Jadiye
Re: commons-graph still on sandbox ?
Hi Gilles, On Tue, Jun 2, 2020, 4:36 AM Gilles Sadowski wrote: > Hello. > > 2020-06-01 22:18 UTC+02:00, Amey Jadiye : > > Thanks for all the information/support guys. I dug into the archives and > > found this[1] is the most recent interest shown by someone in > > commons-graph. > > even created a Jira[2] with lots of digestible information and todo > already > > but never progressed anymore. looks like maintainers left it here[3] with > > no more progress. > > > > I used the existing commons-graph 0.1-SNAPSHOT and basic things look > good > > to me however need more things for my project and I found them in some > > other OSS libs. I will be happy to see commons-graph graduated and see it > > as the proper component, with my free time I will be working on this for > > the next couple of weeks. I see the problem of graph being not on GitHub > > though, I hope communication on Jira will suffice and effective to > > communicate the patches (as graph is on svn). > > You can always post a new message with the specific subject > of moving it to git, in order to elicit opinions and, maybe, > conditions. > Let me do that, it be good we move for further management of code and contribution. > > > > > I see some 16 Jiras open right now in the sandbox[4] so I will pick up > some > > of them. I like the idea to compare the commons-graph with other > libraries > > and that makes roadmap to have all the features plus some more which are > > not even in them. > > > > Now to start with I wanted to clear little confusion with what is > released > > and what's not, I see two releases of commons-graph on maven central[5] > it > > shows apache feather on it not sure if commons PMC released it with fork? > > versions are 0.8 and 0.8.1 however site[6] shows just a 0.1-SNAPSHOT. I > > went further to compare code decompiled from maven central jar(0.8.1) > with > > what's in svn(0.1-SNAPSHOT) *differences are huge*, leaving it. and > > focusing on whats on svn. > > > > since the commons-graph is not as huge as some of the other commons > > projects to be modular at this point. we should progress it with a single > > module and after it stabilized in proper we can think of modularization. > > IMHO, it is preferable to make the component modular > sooner (while it is relatively small) rather than later. > As this will require to determine which parts need to > belong together and the (acyclic graph of) dependencies, > it will probably help improve the design. > If that's the case it should be 1st thing to do, I will create structure and propose for opinions. > > > let me know your opinions please. > > In the list of projects that use a graph abstraction, there is > "Commons RDF". I guess that it would be interesting to see > whether/how it could depend on "Commons Graph". > > Regards, > Gilles > > > > > [1] https://markmail.org/message/2xrwjomgkhlxsezm > > > > [2] https://issues.apache.org/jira/browse/SANDBOX-458 > > > > [3] https://markmail.org/message/niudr4rdz46sjis2 > > > > [4] > > > https://issues.apache.org/jira/browse/SANDBOX-458?jql=project%20%3D%20SANDBOX%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20graph%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC > > > > [5] https://mvnrepository.com/artifact/commons-graph/commons-graph/0.8.1 > > > > [6] https://commons.apache.org/sandbox/commons-graph/ > > > > Regards, > > Amey Jadiye > > > > On Sun, May 31, 2020 at 10:22 PM Matt Sicker wrote: > > > >> I have a vague interest in this library as Jenkins includes a bunch of > >> graph logic for scheduling builds and such. It'd be nice to use a > >> proper graph API someday. :) > >> > >> On Sat, 30 May 2020 at 19:34, Bruno P. Kinoshita > >> wrote: > >> > > >> > Hi Amey! > >> > > >> > > >> > >> 3. Any pending work or jiras available which I can help to graduate > >> commons > >> > >> graph? this is not available > >> https://issues.apache.org/jira/projects/GRAPH ? > >> > > > >> > >Strange; again maybe the reason is in the ML archive. > >> > > >> > > >> > I believe projects in the Sandbox use the common JIRA project > >> > "SANDBOX": > >> https://issues.apache.org/jira/projects/SANDBOX > >> > > >> > > >> > And each component has a component under the SANDBOX project. The > graph &
Re: commons-graph still on sandbox ?
Thanks for all the information/support guys. I dug into the archives and found this[1] is the most recent interest shown by someone in commons-graph. even created a Jira[2] with lots of digestible information and todo already but never progressed anymore. looks like maintainers left it here[3] with no more progress. I used the existing commons-graph 0.1-SNAPSHOT and basic things look good to me however need more things for my project and I found them in some other OSS libs. I will be happy to see commons-graph graduated and see it as the proper component, with my free time I will be working on this for the next couple of weeks. I see the problem of graph being not on GitHub though, I hope communication on Jira will suffice and effective to communicate the patches (as graph is on svn). I see some 16 Jiras open right now in the sandbox[4] so I will pick up some of them. I like the idea to compare the commons-graph with other libraries and that makes roadmap to have all the features plus some more which are not even in them. Now to start with I wanted to clear little confusion with what is released and what's not, I see two releases of commons-graph on maven central[5] it shows apache feather on it not sure if commons PMC released it with fork? versions are 0.8 and 0.8.1 however site[6] shows just a 0.1-SNAPSHOT. I went further to compare code decompiled from maven central jar(0.8.1) with what's in svn(0.1-SNAPSHOT) *differences are huge*, leaving it. and focusing on whats on svn. since the commons-graph is not as huge as some of the other commons projects to be modular at this point. we should progress it with a single module and after it stabilized in proper we can think of modularization. let me know your opinions please. [1] https://markmail.org/message/2xrwjomgkhlxsezm [2] https://issues.apache.org/jira/browse/SANDBOX-458 [3] https://markmail.org/message/niudr4rdz46sjis2 [4] https://issues.apache.org/jira/browse/SANDBOX-458?jql=project%20%3D%20SANDBOX%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20graph%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC [5] https://mvnrepository.com/artifact/commons-graph/commons-graph/0.8.1 [6] https://commons.apache.org/sandbox/commons-graph/ Regards, Amey Jadiye On Sun, May 31, 2020 at 10:22 PM Matt Sicker wrote: > I have a vague interest in this library as Jenkins includes a bunch of > graph logic for scheduling builds and such. It'd be nice to use a > proper graph API someday. :) > > On Sat, 30 May 2020 at 19:34, Bruno P. Kinoshita wrote: > > > > Hi Amey! > > > > > > >> 3. Any pending work or jiras available which I can help to graduate > commons > > >> graph? this is not available > https://issues.apache.org/jira/projects/GRAPH ? > > > > > >Strange; again maybe the reason is in the ML archive. > > > > > > I believe projects in the Sandbox use the common JIRA project "SANDBOX": > https://issues.apache.org/jira/projects/SANDBOX > > > > > > And each component has a component under the SANDBOX project. The graph > issues are under the graph component: > https://issues.apache.org/jira/browse/SANDBOX-460?jql=project%20%3D%20SANDBOX%20AND%20component%20%3D%20Graph > > > > > > Coincidentally, I also am working on a project with graphs, and > yesterday started looking for cyclic graph unfolding algorithms to do some > experiments. Even though my project is in Python, I was going to look at > the commons-graph to see if there was any useful code there. > > > > > > > > Also, I **think** someone mentioned something about bringing graph > algorithms to commons-collections. It might be worth checking if there's > any overlap work in collections > > > > > > > > Cheers > > > > Bruno > > > > > > On Sunday, 31 May 2020, 1:12:56 am NZST, Gilles Sadowski < > gillese...@gmail.com> wrote: > > > > > > > > > > > > Hello. > > > > Le sam. 30 mai 2020 à 14:12, Amey Jadiye a écrit > : > > > > > > Hi All, > > > > > > I'm working on an interesting project which uses Graph, I knew there is > > > commons-graph available and I'm trying to use it. I have a couple of > > > questions. > > > > > > 1. Why graph in the sandbox? > > > > Probably because work stopped before a first release. > > > > It might be worth digging into the ML archive in order to > > know why that happened. > > > > > any plan of releasing it with 1.0 ? > > > > No. But you may come up with one. :-) > > > > > 2. I don't see its repo on GitHub thus I cant contribute a > > > few improvements/additions I'
Re: commons-graph still on sandbox ?
Hi Gilles, I found some useful things in jira-sandbox with component name Graph. I will dig some more important things and come up with some plan. Thanks for your help. Regards, Amey On Sat, May 30, 2020 at 6:42 PM Gilles Sadowski wrote: > Hello. > > Le sam. 30 mai 2020 à 14:12, Amey Jadiye a écrit : > > > > Hi All, > > > > I'm working on an interesting project which uses Graph, I knew there is > > commons-graph available and I'm trying to use it. I have a couple of > > questions. > > > > 1. Why graph in the sandbox? > > Probably because work stopped before a first release. > > It might be worth digging into the ML archive in order to > know why that happened. > > > any plan of releasing it with 1.0 ? > > No. But you may come up with one. :-) > > > 2. I don't see its repo on GitHub thus I cant contribute a > > few improvements/additions I'm thinking? > > You could install and use Subversion, providing patches > through JIRA. > > > any plan of moving from svn to git? > > IMHO not before we know the answer to your first question. > > > 3. Any pending work or jiras available which I can help to graduate > commons > > graph? this is not available > https://issues.apache.org/jira/projects/GRAPH ? > > Strange; again maybe the reason is in the ML archive. > > 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
commons-graph still on sandbox ?
Hi All, I'm working on an interesting project which uses Graph, I knew there is commons-graph available and I'm trying to use it. I have a couple of questions. 1. Why graph in the sandbox? any plan of releasing it with 1.0 ? 2. I don't see its repo on GitHub thus I cant contribute a few improvements/additions I'm thinking? any plan of moving from svn to git? 3. Any pending work or jiras available which I can help to graduate commons graph? this is not available https://issues.apache.org/jira/projects/GRAPH ? Regards, Amey To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Email validation
Hi Amit, Yes you can use EmailValidator from commons-validator, it can validate all kind of email addresses. It internally uses DomainValidator for tld validations. for all the details about tlds you can refer the below source code. https://github.com/apache/commons-validator/blob/master/src/main/java/org/apache/commons/validator/routines/DomainValidator.java Regards, Amey On Thu, May 28, 2020 at 7:58 PM Amit Gadaley wrote: > Hello All, > > I have the following questions: > > Does the validator component able to validate valid email addresses like > contact@armazen.design? > > Does it take care of all the valid domains > <https://data.iana.org/TLD/tlds-alpha-by-domain.txt>? > -- > Kind Regards, > Amit Gadaley > *Technical Consultant* > *HotWax Systems* > *Enterprise open source experts* > cell: +91-95845-93069 > office: 0731-409-3684 > http://www.hotwaxsystems.com > -- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons IO 2.7 based on RC1
Checked Commons IO 2.7 - RC1 and here is my +1 . 1. Build and Tests look good. 2. Clirr looks good. 3. Rat is good. 4. Checkstyle is good. 5. Hashes and Site look good. Checked on:- Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-18T00:03:14+05:30) Maven home: /usr/lib/maven/apache-maven-3.5.4 Java version: 1.8.0_181, vendor: Oracle Corporation, runtime: /usr/lib/jvm/jdk1.8.0_181/jre Default locale: en_IN, platform encoding: UTF-8 OS name: "linux", version: "4.15.0-20-generic", arch: "amd64", family: "unix" Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-18T00:03:14+05:30) Maven home: /usr/lib/maven/apache-maven-3.5.4 Java version: 11.0.6, vendor: Ubuntu, runtime: /usr/lib/jvm/java-11-openjdk-amd64 Default locale: en_IN, platform encoding: UTF-8 OS name: "linux", version: "4.15.0-20-generic", arch: "amd64", family: "unix" Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-18T00:03:14+05:30) Maven home: /usr/lib/maven/apache-maven-3.5.4 Java version: 13.0.1, vendor: Oracle Corporation, runtime: /usr/lib/jvm/jdk-13.0.1 Default locale: en_IN, platform encoding: UTF-8 OS name: "linux", version: "4.15.0-20-generic", arch: "amd64", family: "unix" Regards, Amey On Mon, May 25, 2020 at 2:00 AM Gary Gregory wrote: > We have fixed quite a few bugs and added some significant enhancements > since Apache Commons IO 2.6 was released, so I would like to release Apache > Commons IO 2.7. > > Apache Commons IO 2.7 RC1 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/io/2.7-RC1 (svn > revision > 39753) > > The Git tag commons-io-2.7-RC1 commit for this RC is > 6efbccc88318d15c0f5fdcfa0b87e3dc980dca22 which you can browse here: > > > https://gitbox.apache.org/repos/asf?p=commons-io.git;a=commit;h=6efbccc88318d15c0f5fdcfa0b87e3dc980dca22 > You may checkout this tag using: > git clone https://gitbox.apache.org/repos/asf/commons-io.git --branch > commons-io-2.7-RC1 commons-io-2.7-RC1 > > Maven artifacts are here: > > > https://repository.apache.org/content/repositories/orgapachecommons-1498/commons-io/commons-io/2.7/ > > These are the artifacts and their hashes: > > #Release SHA-512s > #Sun May 24 16:10:47 EDT 2020 > > commons-io-2.7-bin.tar.gz=5bcb609bd0e1e96665ff06529b29cb35e77358e49cf9230a5b71202c616250bc045777a0f64428ef4be17211dff5e24116f6764d41e0aa3d249f048d344debf4 > > commons-io-2.7-bin.zip=32dfa4621204d48fe51c32ccdda87c3864bea5b88ff910b00d197aa698e69135ea003e9c7559085e1cd20580a739173fb62cc6514320094a614b36a5e35d9ab1 > > commons-io-2.7-javadoc.jar=230c9e7747d060574ffe0a4ad09cba17e8194a24c652352b350194ec63924fa4251e0cd8e9cdb5d752906256ae030750251a0d5c39e97d460c802b2197a432cc > > commons-io-2.7-sources.jar=d8fd208cb67b31f8ce6f6cfa1cf55e66709503f435aeaf5c5102d82eda0da5c79d30058647e9a37c6f49e9b982a22ed98492e00e45155f03a6b126e0de29f4ea > > commons-io-2.7-src.tar.gz=9898b59c2aebdc1c51a7f8aca14e3080a08b766404c2aff091b204ba55870129dd95643665a6d46e15e94cd9d4cb280488ab0a28a1c51f43d132f839b742edc3 > > commons-io-2.7-src.zip=a635c0345690aebe57dd74dfbef12581addaebc6d973c8d7ef174e1d67b2f824260a52cd005012f0efbac465f7ef3681f01f1cdb23c7d28202acc080a8703c41 > > commons-io-2.7-test-sources.jar=91d07cd12747cd2daeb399f330f565eff4d3919c00aad283b18bbd66417384402fa9a0ebb608fd0ad2482c2d214c016ead57de2288a0da7055faca229c3cee55 > > commons-io-2.7-tests.jar=2eaaa3280d7e95a8eed1308b97b0b2666b818ba644a23e37b0394498733f92ba412bf664248559616f708b6e222b439e6201d4cf4aedfdc62f65c72b0784567d > > commons-io-2.7.jar.asc=e00353543e02498efb3536bedb564bd40864cf5cc6414ec99336b657e021c50365cba978bb7619ddd06252699855cb58b79c9b36e258a11dca9744b16ab6d741 > > I have tested this with: > > mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site > deploy > > using: > > Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) > Maven home: C:\Java\apache-maven-3.6.3\bin\.. > Java version: 1.8.0_251, vendor: Oracle Corporation, runtime: C:\Program > Files\Java\jdk1.8.0_251\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > > Details of changes since 2.6 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/io/2.7-RC1/RELEASE-NOTES.txt > > > https://dist.apache.org/repos/dist/dev/commons/io/2.7-RC1/site/changes-report.html > > Site: > > https://dist.apache.org/repos/dist/dev/commons/io/2.7-RC1/site/index.html > (note some *relative* links are broken and the 2.7 directories are not > yet created - these will be OK once the site is deployed.) > > JApiCmp Report
Re: [all] How PRs could be better
We might need to develop a plugin to achieve this, and yes as Jochen mentioned this is just a scenario for bug fixes, not for new functionality and enhancements. 1. Plugin must-have functionality like sure-fire to execute the test cases. 2. Plugin must have the functionality to use git, so it can access (HEAD-1) version of src/main/java 3. Plugin should have the functionality to compile [HEAD-1] src and /src/test/java 4. Call this plugin:check in defaultGoals in pom.xml so GH will mark PR red for problems. Regards, Amey On Thu, Feb 20, 2020 at 7:23 PM Gary Gregory wrote: > Hi All: > > I wonder if any of you have an ideas regarding the following. > > When looking at _some_ PRs (that are green on GitHub, build with tests and > other checks passing, able merge OK), I like to apply only the test changes > locally and verify that the main code fails. Then I continue my > evaluation. Obviously if a new or modified test passes, the test or main > change is no good. So yes, a new test for new main code would not even > compile and that's OK. > > It think it would be great if GH could be made to do this two step for us: > - The tests should fail if only the test changes are applied, if not the PR > is red. > - If the tests fail, then GH can evaluate the whole PR. > > How the tests fail and where I'll leave aside for now. > > Thoughts? > > Gary > -- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons CSV 1.8 based on RC2
Checked RC2 of Commons CSV 1.8 and here is my +1 (non-binding). 1. Build and Tests look good. 2. Clirr looks good. 3. Rat is good. 4. Spotbug looks good (I wonder why dont we have it in plugins ? ),[there is one issue with spotbug but i saw in comments its intentionaly done, so okey] 5. Checkstyle is good. 6. Hashes and Site look good. Checked on:- Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-18T00:03:14+05:30) Maven home: /usr/lib/maven/apache-maven-3.5.4 Java version: 1.8.0_181, vendor: Oracle Corporation, runtime: /usr/lib/jvm/jdk1.8.0_181/jre Default locale: en_IN, platform encoding: UTF-8 OS name: "linux", version: "4.15.0-20-generic", arch: "amd64", family: "unix" Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-18T00:03:14+05:30) Maven home: /usr/lib/maven/apache-maven-3.5.4 Java version: 11.0.6, vendor: Ubuntu, runtime: /usr/lib/jvm/java-11-openjdk-amd64 Default locale: en_IN, platform encoding: UTF-8 OS name: "linux", version: "4.15.0-20-generic", arch: "amd64", family: "unix" Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-18T00:03:14+05:30) Maven home: /usr/lib/maven/apache-maven-3.5.4 Java version: 13.0.1, vendor: Oracle Corporation, runtime: /usr/lib/jvm/jdk-13.0.1 Default locale: en_IN, platform encoding: UTF-8 OS name: "linux", version: "4.15.0-20-generic", arch: "amd64", family: "unix" Regards, Amey On Sun, Feb 2, 2020 at 7:26 AM Gary Gregory wrote: > We have fixed quite a few bugs and added some significant enhancements > since Apache Commons CSV 1.7 was released, so I would like to release > Apache Commons CSV 1.8. > > Apache Commons CSV 1.8 RC2 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/csv/1.8-RC2 (svn > revision 37829) > > The Git tag commons-csv-1.8-RC2 commit for this RC is > 660f7c9f853092ec8abf5d6c81d260e3c80c2194 which you can browse here: > > > https://gitbox.apache.org/repos/asf?p=commons-csv.git;a=commit;h=660f7c9f853092ec8abf5d6c81d260e3c80c2194 > You may checkout this tag using: > git clone https://gitbox.apache.org/repos/asf/commons-csv.git --branch > commons-csv-1.8-RC2 commons-csv-1.8-RC2 > > Maven artifacts are here: > > > https://repository.apache.org/content/repositories/orgapachecommons-1490/org/apache/commons/commons-csv/1.8/ > > These are the artifacts and their hashes: > > #Release SHA-512s > #Sat Feb 01 20:19:25 EST 2020 > > commons-csv-1.8-bin.tar.gz=ed0ebd0fdae603480b83dca93a1591161c5939b69306ab8eab17e4cd578157f3aadfe81796ec4c180b6e0f9a143507ffcfb123fe181163cf78b3ca0d1c7c9438 > > commons-csv-1.8-bin.zip=e9ff3bfef662e89b15019a33272e3a44e68cc8ee3c44fa2559021612158f154180b8e5bf0704f5e2453ed5a36061df76bdf9f9d36918c11e0a311107a653317c > > commons-csv-1.8-javadoc.jar=c26f284b98adf6321d84dd426ab8fbbf7ab1d4e3c43bfb62b9b3ce0706399a6034837a8f1164fc66f810c8282a82f168b0ab077d917e45991df337ece6b61d3c > > commons-csv-1.8-sources.jar=4d716b1cb7c2e75253bc7e89a49caf5acb80112974ca4211a5dfabcca5602177bcc2f0796a23f4fbed3eb2f84212507aac124b44acef80b424bdf1f0862d7069 > > commons-csv-1.8-src.tar.gz=e0a7f7dbb0bf381f0f8f703e0ccb689f96c0a610b7afbd771cfeecab7042416f6dddc15c0a6e9a23f157da87c2bf3f16efb2e2aeb135ef1ac8c7306659936443 > > commons-csv-1.8-src.zip=4703f33559ac1fc90aaf5d86408bc593554ef251d01ea5b14d24946d1cd9c7dab74ff96711375befec2b0314d53f907318494d3ba943982c6eb344af29cf6236 > > commons-csv-1.8-test-sources.jar=d0016b3c8ce139a775f376c1b268295f553b97487ce1a9e1a1cce20e3d0b9e709143a44f22c02aa4fc1e1ecc4812de82c14c1b082c644c5ca5bba80230140405 > > commons-csv-1.8-tests.jar=11c109f650643fe8f9da6f46c9c6467728bdbf89484d74a8a71ce1d0b347d5e4f16228eaeb6d1507de2244d7ebea0fc9f5efa869ce5d535ad5d0fa0306cb6dc9 > > I have tested this with 'mvn -V -Prelease -Ptest-deploy -P jacoco -P > japicmp clean package site deploy' using: > > Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) > Maven home: C:\Java\apache-maven-3.6.3\bin\.. > Java version: 1.8.0_241, vendor: Oracle Corporation, runtime: C:\Program > Files\Java\jdk1.8.0_241\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > > Details of changes since 1.7 are in the release notes: > > > https://dist.apache.org/repos/dist/dev/commons/csv/1.8-RC2/RELEASE-NOTES.txt > > > https://dist.apache.org/repos/dist/dev/commons/csv/1.8-RC2/site/changes-report.html > > Site: > > https://dist.apache.org/repos/dist/dev/commons/csv/1.8-RC2/site/index.html > (note some *relative* links are broken and the 1.8 directories are not > yet created - these will be OK once the site is deployed.) > &g
Re: [VOTE] Release Apache Commons DbUtils 1.8 based on RC2
Looks good with tests, rat, clirr, spotbug and javadoc. I can see 4 errors with checkstyle but they seem to be minor. checked with java 8 and 11. hashes and sig are fine. +1 (non-binding) Regards, Amey On Thu, Jan 9, 2020 at 12:20 PM Carl Hall wrote: > We have fixed quite a few bugs and added some significant enhancements > since Apache Commons DbUtils 1.7 was released, so I would like to release > Apache Commons DbUtils 1.8. > > RC2 handles closing connections only when owned, and addresses generated > javadoc, NOTICE year update, and release notes detail. > > Apache Commons DbUtils 1.8 RC2 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/dbutils/1.8-RC2 (svn > revision 37533) > > The Git tag commons-dbutils-1.8-RC2 commit for this RC is > 9be04e5cc990deee3ba672aa8060c523db897b7a which you can browse here: > > https://gitbox.apache.org/repos/asf?p=commons-dbutils.git;a=commit;h=9be04e5cc990deee3ba672aa8060c523db897b7a > > You may checkout this tag using: > git clone https://gitbox.apache.org/repos/asf/commons-dbutils.git > --branch commons-dbutils-1.8-RC2 commons-dbutils-1.8-RC2 > > Maven artifacts are here: > > https://repository.apache.org/service/local/repositories/orgapachecommons-1488/content/commons-dbutils/commons-dbutils/1.8/ > > These are the artifacts and their hashes: > > #Release SHA-512s > #Wed Jan 08 22:43:42 PST 2020 > > commons-dbutils-1.8-tests.jar=0228b8f564642709b0581434f39433f872c77891b5a5d70f473aa8e6cfb14721890982fc4afcde064795ca63753d50ecfc2a173665174bf6fc2683af9770eed9 > > commons-dbutils-1.8-bin.tar.gz.asc=ac5b2da84f1ca0f4605b61583c7d907cb68774a229620d08e7c36e4513435ffbebeb31cae313411e6b0f9dd70e60d55317826e14a43c7c47dcf1c98db03f2396 > > commons-dbutils-1.8-test-sources.jar=075ac4a74cad06a34d901c088f323c59dbe1b9eea076404212ed63b7eb6fa3a266ada20aa63264e89c4203d8d6140fb556acd89ff4e08b21f3f9693de11543a5 > > commons-dbutils-1.8-test-sources.jar.asc=baf8d0e9477d02eac7c3f4be5ac9358378bf46778b4c3159586b336e9300c1ae8c89dd80b22daaeb6b0aafe09c3a6277baddef9e8898c990986cc57df989 > > commons-dbutils-1.8.pom.asc=659f6bfda15f588d00bd53b4204ab2de8eba20a5e484619a1770816e9cb7372846499bc87b9b7629a3fc0c6e3b4f1b740362468aea232286318feeddc4c3bfc5 > > commons-dbutils-1.8-javadoc.jar=115b21ecf633185aa055ce2392ce6298bc45a50278fbce10892ee9493293cdde39149f2ff739848f2557058c7e5c866dcb765e2773a28f890725ddf328c73259 > > commons-dbutils-1.8-sources.jar.asc=2e1709b4f9dfc1f9320127dded40b9af9c19a5e249aaac9deadd38aee572a28ecb7ef8de559b93c97b6093596cadd70e180b99787b82965e0f5d8376adfac8fb > > commons-dbutils-1.8-bin.zip.asc=e5cb25909f68e5d0a3249ca484d10b97b859ed56e92072b13ca64c85d18686605189703e2e146343247b6a64e3e20b4c7e07e12f40b37c87d305a9d71e951581 > > commons-dbutils-1.8-bin.tar.gz=c8a9cf0c59a64cbe4717edeb377a85fd8395c4bbd9eb124d24099d04fd6e8e3b87063bf4bfaca63e58d8deb80a651b4d9fc03c00db56f0ea0d93053f61138f4f > > commons-dbutils-1.8-src.tar.gz=5277ebf4ed36a4301ce7a6280885360ea51ebc82771a01405684397fa33144c00214e5ac7a3b4aad75ec4dd6d3eb46ef083321bf03414dce29982c553da1360e > > commons-dbutils-1.8-javadoc.jar.asc=9a6bca512db25dcd6be9215862b1f04cfd86ad58f6c21d3cbcebe1ad9137e5dc3417d05db915acc4fc6f22ef0c40893c401a77568148d714f66375ea66da2078 > > commons-dbutils-1.8-src.tar.gz.asc=d7ace200a63c2ee705cda7d4d5b62d401b8cb9e54b5b4a582e3e8f0c62f16ac964ebf5f440ad39f60344d28771f6942833c241c9163ced70f5bb7dfd256989c5 > > commons-dbutils-1.8-src.zip.asc=3c4e20ceb0a0c071cc425be3a4604651de47df2be7bf1985525d319fc3c8035299a75ba558172411338d0174d504cddd7c22dc35d334a21b043f885fdabcd736 > > commons-dbutils-1.8-tests.jar.asc=a9df8e97c85f437223ae0ba02fafba542c978a44ec12a61cf742e261e238e4bd9a4d7bb1239c8101aeede7d88ba4ad647ceb2eaececb1cc3c4027d9308491a00 > > commons-dbutils-1.8-sources.jar=425dcae024bc592ce38238fde0e2d7eaf919fa238d64e23796c383afa30892d6c4a7850e9f405fe7d0fcd32dde97568f1ef2e708cbb193311746744ce0425fa0 > > commons-dbutils-1.8-bin.zip=ee4819761efccc4ba3de929672a81415a787775eff0175ea782687a669e305b159e483f21e38f020e5459e3aff11adff02aa762d4aa7c0b35a2925e45730d61d > > commons-dbutils-1.8.jar.asc=e7555a17fd6a85aa0b80d54e163809bfae839a5b23f4e57c5d804fb039ec37599df08d45dadef8b33bc7ee26d17c1612062bdaf2c07ecc576773c583ed9048ff > > commons-dbutils-1.8-src.zip=5363310bda5f09337992f7d2ed4b73b3d76d8107101584a1d14487a55665476ff47989fb4e2ddbbe139b5fe36faf7a7b14d99aaf89cb8dc48c605531d61d35b9 > > > (no need for .asc hashes!) > > I have tested this with ***'mvn clean install site'*** using: > *** > Use the output from "mvn -version" for each combination you tested. > *** > > Details of changes since 1.7 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/dbutils/1.8-RC2/RELEASE-NOTES.txt > > https://dist.apache.org/rep
Re: [All] Sonarcloud reports zero coverage
On Mon, Jan 27, 2020, 4:57 AM Gilles Sadowski wrote: > Hello. > Hi, > > Le dim. 26 janv. 2020 à 18:06, Amey Jadiye a écrit > : > > > > For almost all the repo[1][2] this is suddenly dropped I can see an event > > in coverage activity written as "Quality Profile: Changes in 'Sonar way' > > (Java)". > > I see there are some changes done on profile[3] on 7th Jan, It must be > that > > change broke down the coverage. ? > > > > [1] > > > https://sonarcloud.io/project/activity?custom_metrics=coverage=custom=commons-numbers > > [2] > > > https://sonarcloud.io/project/activity?custom_metrics=coverage=custom=commons-rng > > [3] > > > https://sonarcloud.io/organizations/apache/quality_profiles/changelog?language=java=Sonar+way > > Thanks for looking into it. > I too had noticed that "something" is reported as changed, but > couldn't figure out what... > > Regards, > Gilles > That "something" is also given in the [3] link I provided. :), Anyway, infra admin can revert/correct it as i see that change is breaking many other than commons apache projects. Regards, Amey > > > Regards, > > Amey > > > > On Wed, Jan 15, 2020 at 9:17 PM Gilles Sadowski > > wrote: > > > > > Hello. > > > > > > "Sonar" reports are created for several projects, a.o. > > > https://sonarcloud.io/dashboard?id=commons-numbers > > > https://sonarcloud.io/dashboard?id=commons-geometry > > > https://sonarcloud.io/dashboard?id=commons-rng > > > https://sonarcloud.io/dashboard?id=commons-statistics > > > for which coverage is now reported as 0%, although it was reported > > > correctly earlier. > > > > > > Regards, > > > Gilles > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [All] Sonarcloud reports zero coverage
For almost all the repo[1][2] this is suddenly dropped I can see an event in coverage activity written as "Quality Profile: Changes in 'Sonar way' (Java)". I see there are some changes done on profile[3] on 7th Jan, It must be that change broke down the coverage. ? [1] https://sonarcloud.io/project/activity?custom_metrics=coverage=custom=commons-numbers [2] https://sonarcloud.io/project/activity?custom_metrics=coverage=custom=commons-rng [3] https://sonarcloud.io/organizations/apache/quality_profiles/changelog?language=java=Sonar+way Regards, Amey On Wed, Jan 15, 2020 at 9:17 PM Gilles Sadowski wrote: > Hello. > > "Sonar" reports are created for several projects, a.o. > https://sonarcloud.io/dashboard?id=commons-numbers > https://sonarcloud.io/dashboard?id=commons-geometry > https://sonarcloud.io/dashboard?id=commons-rng > https://sonarcloud.io/dashboard?id=commons-statistics > for which coverage is now reported as 0%, although it was reported > correctly earlier. > > Regards, > Gilles > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LAZY][VOTE] Release Apache Commons Parent 50 based on RC1
On Sun, Dec 15, 2019 at 2:44 AM Alex Herbert wrote: > > > > On 14 Dec 2019, at 17:24, Amey Jadiye wrote: > > > > On Sat, Dec 14, 2019 at 9:35 PM Alex Herbert <mailto:alex.d.herb...@gmail.com>> > > wrote: > > > >> > >> > >>> On 14 Dec 2019, at 14:47, Amey Jadiye ameyjad...@gmail.com>> wrote: > >>> > >>> Looks good to me. > >>> +1 (Non-Binding) > >>> > >>> Few things observed in the mvn site. > >>> 1. In site >> Project Reports >> Changes : - Changes are not mentioned > >>> since version 47, it's nice to see a short description of changes. > >> > >> Where are you looking? I generated a site for parent for the RC just to > >> show the changes and RAT report. There is a full changes report [1]. It > is > >> not clear but the top of the report is a summary table. If you click on > the > >> 50 it is a link to further down the page [2]. > >> > >> I'm sorry for being a little less descriptive, I just thought we can > put a > > bit more description in changes-report.html "Description" column right > now > > it states just "Release version 50". I can see we have a full description > > on the link "50”. > > OK. I see your point now. I can update the description of the release in > the changes.xml to have more summary of the changes. I’ll do this after the > release as it is not a blocker. > > Yup, not a blocker. I'm already +1 (non-binding) for the release. > I can do this for release 50 but was not involved for earlier releases. > I’ll look at those and try and improve their summary too. Anyone interested > can just scroll through the actual changes listed in the report. > > Thank you! -- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LAZY][VOTE] Release Apache Commons Parent 50 based on RC1
On Sat, Dec 14, 2019 at 9:35 PM Alex Herbert wrote: > > > > On 14 Dec 2019, at 14:47, Amey Jadiye wrote: > > > > Looks good to me. > > +1 (Non-Binding) > > > > Few things observed in the mvn site. > > 1. In site >> Project Reports >> Changes : - Changes are not mentioned > > since version 47, it's nice to see a short description of changes. > > Where are you looking? I generated a site for parent for the RC just to > show the changes and RAT report. There is a full changes report [1]. It is > not clear but the top of the report is a summary table. If you click on the > 50 it is a link to further down the page [2]. > > I'm sorry for being a little less descriptive, I just thought we can put a bit more description in changes-report.html "Description" column right now it states just "Release version 50". I can see we have a full description on the link "50". > As far as I know there is not a live site for parent. There is a general > site for commons but that is not built from parent. > > If you ever want to know the changes in parent then you can always check > the RELEASE-NOTES.txt in the source repo. > Got it, Thanks. > [1] > https://dist.apache.org/repos/dist/dev/commons/commons-parent/50-RC1/site/changes-report.html > < > https://dist.apache.org/repos/dist/dev/commons/commons-parent/50-RC1/site/changes-report.html > > > [2] > https://dist.apache.org/repos/dist/dev/commons/commons-parent/50-RC1/site/changes-report.html#a50 > < > https://dist.apache.org/repos/dist/dev/commons/commons-parent/50-RC1/site/changes-report.html#a50 > > > > > 2. In site >> COMMONS : - link of Components, Sandbox, Dormant is not > > working, if not required can we remove it from Parent's site? > > This is due to the site being a staged site outside of the commons site > directory structure. The vote e-mail always states: > > ‘note some *relative* links are broken’ > > So these links are broken. They work on the live site [3,4]. > > Cool, Thank you! :) > Again I do not think this is part of commons-parent. There is no site > documentation in the project repo. The parent is just a POM to be used by > other projects. > > Thanks for reviewing. > > Alex > > [3] https://commons.apache.org/sandbox.html < > https://commons.apache.org/sandbox.html> > [4] https://commons.apache.org/dormant.html < > https://commons.apache.org/dormant.html> > > > > Regards, > > Amey > > > > On Fri, Dec 13, 2019 at 7:11 PM Alex Herbert > > wrote: > > > >> We have fixed quite a few bugs and added some significant enhancements > >> since Apache Commons Parent 49 was released, so I would like to release > >> Apache Commons Parent 50. > >> > >> Apache Commons Parent 50 RC1 is available for review here: > >> https://dist.apache.org/repos/dist/dev/commons/commons-parent/50-RC1 > >> (svn revision 37200) > >> > >> The Git tag commons-parent-50-RC1 commit for this RC is > >> commons-parent-50-RC1 which you can browse here: > >> > >> > https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=commons-parent-50-RC1 > >> You may checkout this tag using: > >> git clone https://gitbox.apache.org/repos/asf/commons-parent.git > >> --branch commons-parent-50-RC1 commons-parent-50-RC1 > >> > >> Maven artifacts are here: > >> > >> > https://repository.apache.org/content/repositories/orgapachecommons-1481/org/apache/commons/commons-parent/50/ > >> > >> These are the artifacts and their hashes: > >> > >> > >> > commons-parent-50-src.tar.gz.sha512=adfe905788128d72ec2c24f9bf4ff6e8149510c28090ef1330041c3ed3a2734adf0ac11fb83676e2f8f8a6e3f0e2b39054143fa66f49438a0ae4fa7f244bd078 > >> > >> > commons-parent-50-src.zip.sha512=b5274771504389cc3717e7346a5803b318f2aa2b72273d66aabb7bbf7a79a29bc65d10888ce0507b78cc770addfac854ec2a7a66ab0608886d6d6e2993c9a984 > >> > >> > >> I have tested this with 'mvn clean install' using: > >> > >> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; > >> 2018-10-24T19:41:47+01:00) > >> Maven home: /usr/local/apache-maven-3.6.0 > >> Java version: 1.8.0_222, vendor: Private Build, runtime: > >> /usr/lib/jvm/java-8-openjdk-amd64/jre > >> Default locale: en_GB, platform encoding: UTF-8 > >> OS name: "linux", version: "4.4.0-169-generic", arch: "amd64", family: > >> "unix" > >> > >> > >> Details of changes si
Re: [LAZY][VOTE] Release Apache Commons Parent 50 based on RC1
Looks good to me. +1 (Non-Binding) Few things observed in the mvn site. 1. In site >> Project Reports >> Changes : - Changes are not mentioned since version 47, it's nice to see a short description of changes. 2. In site >> COMMONS : - link of Components, Sandbox, Dormant is not working, if not required can we remove it from Parent's site? Regards, Amey On Fri, Dec 13, 2019 at 7:11 PM Alex Herbert wrote: > We have fixed quite a few bugs and added some significant enhancements > since Apache Commons Parent 49 was released, so I would like to release > Apache Commons Parent 50. > > Apache Commons Parent 50 RC1 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/commons-parent/50-RC1 > (svn revision 37200) > > The Git tag commons-parent-50-RC1 commit for this RC is > commons-parent-50-RC1 which you can browse here: > > https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=commons-parent-50-RC1 > You may checkout this tag using: > git clone https://gitbox.apache.org/repos/asf/commons-parent.git > --branch commons-parent-50-RC1 commons-parent-50-RC1 > > Maven artifacts are here: > > https://repository.apache.org/content/repositories/orgapachecommons-1481/org/apache/commons/commons-parent/50/ > > These are the artifacts and their hashes: > > > commons-parent-50-src.tar.gz.sha512=adfe905788128d72ec2c24f9bf4ff6e8149510c28090ef1330041c3ed3a2734adf0ac11fb83676e2f8f8a6e3f0e2b39054143fa66f49438a0ae4fa7f244bd078 > > commons-parent-50-src.zip.sha512=b5274771504389cc3717e7346a5803b318f2aa2b72273d66aabb7bbf7a79a29bc65d10888ce0507b78cc770addfac854ec2a7a66ab0608886d6d6e2993c9a984 > > > I have tested this with 'mvn clean install' using: > > Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; > 2018-10-24T19:41:47+01:00) > Maven home: /usr/local/apache-maven-3.6.0 > Java version: 1.8.0_222, vendor: Private Build, runtime: > /usr/lib/jvm/java-8-openjdk-amd64/jre > Default locale: en_GB, platform encoding: UTF-8 > OS name: "linux", version: "4.4.0-169-generic", arch: "amd64", family: > "unix" > > > Details of changes since 49 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/commons-parent/50-RC1/RELEASE-NOTES.txt > > https://dist.apache.org/repos/dist/dev/commons/commons-parent/50-RC1/site/changes-report.html > > Site: > > https://dist.apache.org/repos/dist/dev/commons/commons-parent/50-RC1/site/index.html > (note some *relative* links are broken and the 50 directories are > not yet created - these will be OK once the site is deployed.) > > RAT Report: > > https://dist.apache.org/repos/dist/dev/commons/commons-parent/50-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 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, > > Alex Herbert, > Release Manager (using key BC87A3FD0A54480F0BADBEBD21939FF0CA2A6567) > > 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-parent.git > --branch commons-parent-50-RC1 commons-parent-50-RC1 > cd commons-parent-50-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) Build the package > > mvn -V clean package > > You can record the Maven and Java version produced by -V in your VOTE > reply. > To gather OS information from a command line: > Windows: ver > Linux: uname -a > > 5) Build the site for a single module project > > Note: Some plugins require the components to be installed instead of > packaged. > > mvn site > Check the site reports in: > - Windows: target\site\index.html > - Linux: target/site/index.html > > -the end- > > > - > 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 BCEL 6.4.1 based on RC1
looks good with rat, japicmp, checkstyle, some warnings with javadoc. checked with java8 and 11. hashes and sig are fine. +1 (non-binding) Regards, Amey On Fri, Sep 27, 2019 at 7:08 AM Gary Gregory wrote: > We have fixed one important bug since Apache Commons BCEL 6.4.0 was > released, so I would like to release Apache Commons BCEL 6.4.1. > > Apache Commons BCEL 6.4.1 RC1 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/bcel/6.4.1-RC1 (svn > revision 36085) > > The Git tag commons-bcel-6.4.1-RC1 commit for this RC is > bebe70de81f2f8912857ddb33e82d3ccc146a24e which you can browse here: > > > https://gitbox.apache.org/repos/asf?p=commons-bcel.git;a=commit;h=bebe70de81f2f8912857ddb33e82d3ccc146a24e > You may checkout this tag using: > git clone https://gitbox.apache.org/repos/asf/commons-bcel.git > --branch > commons-bcel-6.4.1-RC1 commons-bcel-6.4.1-RC1 > > Maven artifacts are here: > > > https://repository.apache.org/content/repositories/orgapachecommons-1472/org/apache/bcel/bcel/6.4.1/ > > These are the artifacts and their hashes: > > #Release SHA-512s > #Thu Sep 26 21:15:47 EDT 2019 > > bcel-6.4.1-bin.tar.gz=937994f22aaaf7dfe1f9a789f6c9968f80b5c9a2929aa0364beffe1b9136f7af98dd6386533f02441f74a9df57e913b4eb9c0598778f31d4ea3cda9b02beabcb > > bcel-6.4.1-bin.zip=94bcd0afa9f6679f7d0e25b5bf3d2901d7e42f4488f6b7f2a5b91827023ca56ef6c5bf2b82996ec196d2b744f1345526f729dc00b3fb58d4b55f8fa7748e5fa1 > > bcel-6.4.1-javadoc.jar=280a79bc811c4c8b9c0249ba98d82a0054dd286ee1009f340231ac9d147709e06800e50c26fd21d8f31d15ab337a9ae30727edd8548f269d968ca7f31eb72abf > > bcel-6.4.1-sources.jar=5761d9e1ba53b9d60f81941f1db581030aaadb5829f429c2897220c13874a7718e26f213bd9f49bbed68fb0a3a8e6375f312ce4c8cd551030d95652209aa7ab2 > > bcel-6.4.1-src.tar.gz=746987c314d3a2bd7308e5cd0b3403c915f09b5127af5980f986a81bccff91cca6098b636fd2f337e8e42f1e3600e8eac14b4f3b0564739b155955603a2e9b7f > > bcel-6.4.1-src.zip=b63f3d53ec3c9cc623475c2383e292aa5fd52f1a8388c162a86b345efd82b3ba199b3ff096baf9a7a4767317b0c928d828c01154394e39bcecf9577668d7b1a6 > > bcel-6.4.1-test-sources.jar=28dd0b17d43552b9b91aed3c1fac042b388f50deaf3953930ce69906e8269ae5850dd402b93f7641266c665c6fd72069f025a590a6f39e907b084ea4db100517 > > bcel-6.4.1-tests.jar=5168dab87d4b49861f4dc8e0fc3522e26175a5faa3010cb5127b0455190c16246f35cf0b86b48ecdc92e4b4107197cef3c1265aade6ba630eb32dcd87ceb9fd7 > > I have tested this with: > > mvn -V -Duser.name=%my_apache_id% > -Dcommons.release-plugin.version=1.7-SNAPSHOT -Ddoclint=none -Prelease > -Ptest-deploy clean package site deploy > > using: > > Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117; > 2019-08-27T11:06:16-04:00) > Maven home: C:\Java\apache-maven-3.6.2\bin\.. > Java version: 1.8.0_221, vendor: Oracle Corporation, runtime: C:\Program > Files\Java\jdk1.8.0_221\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > > Details of changes since 6.4.0 are in the release notes: > > > https://dist.apache.org/repos/dist/dev/commons/bcel/6.4.1-RC1/RELEASE-NOTES.txt > > > https://dist.apache.org/repos/dist/dev/commons/bcel/6.4.1-RC1/site/changes-report.html > > Site: > > > https://dist.apache.org/repos/dist/dev/commons/bcel/6.4.1-RC1/site/index.html > (note some *relative* links are broken and the 6.4.1 directories are > not yet created - these will be OK once the site is deployed.) > > JApiCmp Report (compared to 6.4.0): > > > https://dist.apache.org/repos/dist/dev/commons/bcel/6.4.1-RC1/site/japicmp.html > > RAT Report: > > > https://dist.apache.org/repos/dist/dev/commons/bcel/6.4.1-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 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, > > Gary Gregory, > Release Manager (using key 86fdc7e2a11262cb) > > 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-bcel.git --branch > commons-bcel-6.4.1-RC1 commons-bcel-6.4.1-RC1 > cd commons-bcel-6.4.1-RC1 > > 2) Check Apache licenses > > This step is not required if the site i
Re: [CLI] Option arguments without - or --
On Fri, Mar 29, 2019 at 3:41 PM sebb wrote: > On Fri, 29 Mar 2019 at 07:04, Amey Jadiye wrote: > > > > Hi, > > > > Looks like the functionality is not present in the code base. > > > > I'm proposing the SimpleCommandParser which can implement > CommandLineParser > > for achieving below requirements. let me know your thoughts on this. > > Thanks for the suggestion. > > However, unless I have misunderstood the requirement, parsing looks to > be trivial and not worth the additional effort of creating and > maintaining library code. > well, In that case existing code should be made flexible enough to meet the requirement. I'll think about the changes and raise PR. > > It also seems to be a very uncommon use case, so I doubt that many > people would use the code. > > > Regards, > > Amey > > > > On Wed, Mar 27, 2019 at 11:32 AM Amey Jadiye > wrote: > > > > > Hi, > > > > > > I'm developing a console application and required to get the command > and > > > argument in non traditional fashion where command name dont start with > > > -name=value or --name=value. > > > > > > I expect the cli library should handle in below fashion > > > > > > Push 1 2 3 4 > > > Pull 5 8 9 > > > > > > Where push and Pull is command proceed with their arguments. > > > > > > I searched the library but didn't found such option, does anyone know > how > > > to achieve this with Apache Commons CLI ? > > > > > > If this functionality is not present I can contribute in couple of > weeks. > > > > > > Regards, > > > Amey > > > > > > > > > > -- > > > > - > > > > 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: [CLI] Option arguments without - or --
Hi, Looks like the functionality is not present in the code base. I'm proposing the SimpleCommandParser which can implement CommandLineParser for achieving below requirements. let me know your thoughts on this. Regards, Amey On Wed, Mar 27, 2019 at 11:32 AM Amey Jadiye wrote: > Hi, > > I'm developing a console application and required to get the command and > argument in non traditional fashion where command name dont start with > -name=value or --name=value. > > I expect the cli library should handle in below fashion > > Push 1 2 3 4 > Pull 5 8 9 > > Where push and Pull is command proceed with their arguments. > > I searched the library but didn't found such option, does anyone know how > to achieve this with Apache Commons CLI ? > > If this functionality is not present I can contribute in couple of weeks. > > Regards, > Amey > > -- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[CLI] Option arguments without - or --
Hi, I'm developing a console application and required to get the command and argument in non traditional fashion where command name dont start with -name=value or --name=value. I expect the cli library should handle in below fashion Push 1 2 3 4 Pull 5 8 9 Where push and Pull is command proceed with their arguments. I searched the library but didn't found such option, does anyone know how to achieve this with Apache Commons CLI ? If this functionality is not present I can contribute in couple of weeks. Regards, Amey
Re: [VOTE] Redirect github notifications to issues@
+1 On Wed, 20 Feb 2019, 3:05 am Marcelo Vanzin, wrote: > I'm opening a vote based on recent discussions about the extra noise > generated by github updates going to dev@. So please vote: > > - +1 to redirect github updates of all commons repos to the issues@ list > - -1 to keep things as is > > If the vote passes, I'll take care of opening an infra ticket > referencing the result. > > -- > Marcelo > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [VOTE][RC2] Commons collections 4.3
On Fri, 4 Jan 2019, 5:25 pm Gilles hi. > Hi Gilles, > > On Thu, 3 Jan 2019 22:04:24 +0530, Amey Jadiye wrote: > > Hello Maxim / All > > > > I put little more efforts to find out the possible cause of the > > error. > > In the clirr code, I found the reason for this error and same is > > documented > > in clirr documentation [1]. > > > > A method declaration has been added to the specified interface. This > > is > > always reported as a binary-compatibility error, but in practice, the > > changed class might be used successfully with code compiled against > > the old > > interface depending upon usage patterns. > > > > Old code which invokes methods upon code compiled against the new > > (expanded) interface will continue to work without issues. And old > > code > > which implements the old version of the interface will also continue > > to > > work correctly as long as no code attempts to invoke any of the > > newly-added > > methods against that instance. But the code which (validly) invokes > > one of > > the new methods in the interface against an object which implements > > only > > the old version of the interface will cause an AbstractMethodError to > > be > > thrown at the time the method invocation is attempted. > > IIUC, new code that calls the new methods on [Collections] classes > will crash. Does not look good. > On the other hand, Maxim wrote earlier that a method reported by > Clirr as "new" (cf. below) was in fact present since Java 6... > > Are we then sure that it's a Clirr bug? > If so, why did you not vote "+1" (on the condition that the false > positive is mentioned in the release notes)? > > We could also make some definite progress with an actual code > example that calls the incriminated methods, compiled against the > current version of the library and then run against the current RC, > and see whether it crashes. > Thanks for directions here, I must also check that. Till then I would like to change my vote to -1 (Non Binding) for this release. > Alternatively, we could instate "revapi" in the POM (and disable > Clirr); and if the report is clean, trust that (though "revapi" is > still beta). > > Opinions? > > Gilles > > > > > In 4.2 and 4.3 looks like we have upgraded the java version[2] where > > for > > example for Map interface might have added a few more methods causing > > these > > errors. > > > > For this release, I am voting 0 (Non-Binding) as there is unharmed > > mess > > around the clirr. > > > > rest of the things are OK with this release, I would encourage to > > have > > revapi replacing clirr. > > > > > > [1] http://clirr.sourceforge.net/clirr-core/exegesis.html > > [2] > > > > > https://github.com/apache/commons-collections/commit/482762a13f739631f94d03642b0a55a9b7214c44 > > > > Regards, > > Amey > > > > > > On Thu, Jan 3, 2019 at 11:53 AM Amey Jadiye > > wrote: > > > >> I spared little time on finding issue however didn't found it in > >> clirr(may > >> be hidden somewhere), today will check if clirr maven plugin have > >> any > >> issues. also I saw that few other apache commons modules having same > >> issue > >> and are released. > >> > >> I also gave try on revapi with commons collection4 4.3RC2. > >> revapi:check > >> was clean unlike clirr, looks promising to replace clirr. > >> > >> Regards, > >> Amey > >> > >> On Wed, 2 Jan 2019, 12:31 pm Maxim Solodovnik >> wrote: > >> > >>> Hello All, > >>> > >>> Just checked clirr report one more time > >>> This time I took 1 error and perform investigation: > >>> > >>> "Method 'public java.util.Collection values()' has been added to an > >>> interface" org.apache.commons.collections4.BidiMap > >>> > >>> In fact I don't understand why this error was reported > >>> BidiMap extends java.util.Map > >>> Map has method "public java.util.Collection values()" in all > >>> versions: > >>> https://docs.oracle.com/javase/6/docs/api/java/util/Map.html > >>> https://docs.oracle.com/javase/7/docs/api/java/util/Map.html > >>> https://docs.oracle.com/javase/8/docs/api/java/util/Map.html > >>> > >>> Maybe its clirr issue? > >>> Would appreciate any help with this investigation >
Re: [VOTE][RC2] Commons collections 4.3
Hello Maxim / All I put little more efforts to find out the possible cause of the error. In the clirr code, I found the reason for this error and same is documented in clirr documentation [1]. A method declaration has been added to the specified interface. This is always reported as a binary-compatibility error, but in practice, the changed class might be used successfully with code compiled against the old interface depending upon usage patterns. Old code which invokes methods upon code compiled against the new (expanded) interface will continue to work without issues. And old code which implements the old version of the interface will also continue to work correctly as long as no code attempts to invoke any of the newly-added methods against that instance. But the code which (validly) invokes one of the new methods in the interface against an object which implements only the old version of the interface will cause an AbstractMethodError to be thrown at the time the method invocation is attempted. In 4.2 and 4.3 looks like we have upgraded the java version[2] where for example for Map interface might have added a few more methods causing these errors. For this release, I am voting 0 (Non-Binding) as there is unharmed mess around the clirr. rest of the things are OK with this release, I would encourage to have revapi replacing clirr. [1] http://clirr.sourceforge.net/clirr-core/exegesis.html [2] https://github.com/apache/commons-collections/commit/482762a13f739631f94d03642b0a55a9b7214c44 Regards, Amey On Thu, Jan 3, 2019 at 11:53 AM Amey Jadiye wrote: > I spared little time on finding issue however didn't found it in clirr(may > be hidden somewhere), today will check if clirr maven plugin have any > issues. also I saw that few other apache commons modules having same issue > and are released. > > I also gave try on revapi with commons collection4 4.3RC2. revapi:check > was clean unlike clirr, looks promising to replace clirr. > > Regards, > Amey > > On Wed, 2 Jan 2019, 12:31 pm Maxim Solodovnik >> Hello All, >> >> Just checked clirr report one more time >> This time I took 1 error and perform investigation: >> >> "Method 'public java.util.Collection values()' has been added to an >> interface" org.apache.commons.collections4.BidiMap >> >> In fact I don't understand why this error was reported >> BidiMap extends java.util.Map >> Map has method "public java.util.Collection values()" in all versions: >> https://docs.oracle.com/javase/6/docs/api/java/util/Map.html >> https://docs.oracle.com/javase/7/docs/api/java/util/Map.html >> https://docs.oracle.com/javase/8/docs/api/java/util/Map.html >> >> Maybe its clirr issue? >> Would appreciate any help with this investigation >> >> On Mon, 31 Dec 2018 at 16:53, Gilles >> wrote: >> > >> > On Mon, 31 Dec 2018 07:41:40 +0700, Maxim Solodovnik wrote: >> > > Hello Gilles, >> > > >> > > I already did analysis: [1], all errors are caused by previous >> > > release >> > > 4.3 doesn't introduce any new errors ... >> > > >> > > [1] https://markmail.org/message/l7ftxlvdk4yqxijt >> > >> > I had seen the post but it says: >> > --- >> > these errors are weird. Above classes has no changes comparing to 4.2 >> > --- >> > >> > But IMHO it was not a conclusion: If the cause of the errors was >> > identified, it could have been mentioned in the release notes >> > and/or the [VOTE] email, in order to avoid further questioning. >> > >> > Is the cause the change of supported JDK? >> > >> > Regards, >> > Gilles >> > >> > > >> > > On Mon, 31 Dec 2018 at 07:26, Rob Tompkins >> > > wrote: >> > >> >> > >> I’ll give it a look tonight or in the morning. >> > >> >> > >> -Rob >> > >> >> > >> > On Dec 30, 2018, at 12:25 AM, Maxim Solodovnik >> > >> wrote: >> > >> > >> > >> > No votes after 3 days :( >> > >> > Is there anything wrong with the RC? >> > >> > >> > >> >> On Thu, 27 Dec 2018 at 05:20, Bruno P. Kinoshita >> > >> wrote: >> > >> >> >> > >> >> FWIW I had a similar experience, and realized I was doing `git >> > >> fetch --all`, but it didn't bring the tags. `git fetch --tags` did >> the >> > >> trick. After that I could `git checkout $tag-name` >> > >> >> >> > >> >> Cheers >> > >> >&
Re: [VOTE][RC2] Commons collections 4.3
I spared little time on finding issue however didn't found it in clirr(may be hidden somewhere), today will check if clirr maven plugin have any issues. also I saw that few other apache commons modules having same issue and are released. I also gave try on revapi with commons collection4 4.3RC2. revapi:check was clean unlike clirr, looks promising to replace clirr. Regards, Amey On Wed, 2 Jan 2019, 12:31 pm Maxim Solodovnik Hello All, > > Just checked clirr report one more time > This time I took 1 error and perform investigation: > > "Method 'public java.util.Collection values()' has been added to an > interface" org.apache.commons.collections4.BidiMap > > In fact I don't understand why this error was reported > BidiMap extends java.util.Map > Map has method "public java.util.Collection values()" in all versions: > https://docs.oracle.com/javase/6/docs/api/java/util/Map.html > https://docs.oracle.com/javase/7/docs/api/java/util/Map.html > https://docs.oracle.com/javase/8/docs/api/java/util/Map.html > > Maybe its clirr issue? > Would appreciate any help with this investigation > > On Mon, 31 Dec 2018 at 16:53, Gilles wrote: > > > > On Mon, 31 Dec 2018 07:41:40 +0700, Maxim Solodovnik wrote: > > > Hello Gilles, > > > > > > I already did analysis: [1], all errors are caused by previous > > > release > > > 4.3 doesn't introduce any new errors ... > > > > > > [1] https://markmail.org/message/l7ftxlvdk4yqxijt > > > > I had seen the post but it says: > > --- > > these errors are weird. Above classes has no changes comparing to 4.2 > > --- > > > > But IMHO it was not a conclusion: If the cause of the errors was > > identified, it could have been mentioned in the release notes > > and/or the [VOTE] email, in order to avoid further questioning. > > > > Is the cause the change of supported JDK? > > > > Regards, > > Gilles > > > > > > > > On Mon, 31 Dec 2018 at 07:26, Rob Tompkins > > > wrote: > > >> > > >> I’ll give it a look tonight or in the morning. > > >> > > >> -Rob > > >> > > >> > On Dec 30, 2018, at 12:25 AM, Maxim Solodovnik > > >> wrote: > > >> > > > >> > No votes after 3 days :( > > >> > Is there anything wrong with the RC? > > >> > > > >> >> On Thu, 27 Dec 2018 at 05:20, Bruno P. Kinoshita > > >> wrote: > > >> >> > > >> >> FWIW I had a similar experience, and realized I was doing `git > > >> fetch --all`, but it didn't bring the tags. `git fetch --tags` did the > > >> trick. After that I could `git checkout $tag-name` > > >> >> > > >> >> Cheers > > >> >> Bruno > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> From: Gilles > > >> >> To: dev@commons.apache.org > > >> >> Sent: Thursday, 27 December 2018 9:26 AM > > >> >> Subject: Re: [VOTE][RC2] Commons collections 4.3 > > >> >> > > >> >> > > >> >> > > >> >>> On Wed, 26 Dec 2018 21:21:34 +0100, Gilles wrote: > > >> >>> Hi. > > >> >>> > > >> >>>> On Wed, 26 Dec 2018 20:41:59 +0700, Maxim Solodovnik wrote: > > >> >>>> This is a [VOTE] for releasing > > >> >>>> Apache Commons collections 4.3 > > >> >>>> > > >> >>>> Tag name: > > >> >>>>collections-4.3-RC2 (signature can be checked from git using > > >> >>>> 'git > > >> >>>> tag -v') > > >> >>> > > >> >>> $ git tag -v collections-4.3-RC2 > > >> >>> error: tag 'collections-4.3-RC2' not found. > > >> >>> > > >> >>> Although I see it in the link below... > > >> >>> What is going on? > > >> >> > > >> >> Issue vanished with a fresh "clone". > > >> >> [Sorry for the noise.] > > >> >> > > >> >> > > >> >>>> RC1 was cancelled due to some release steps were not done > > >> >>>> > > >> >>>> Tag URL: > > >> >>>> > > >> >>
Re: [VOTE] Release Apache Commons Text 1.5 based on RC3
Checked RC3 of Commons Text 1.5, here is my +1 (non-binding). 1. Build and Tests look good. 2. Clirr looks good. 3. Rat is good. 4. Spotbug looks good. 5. Checkstyle is good. 6. Hashes look good. Checked on:- Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-18T00:03:14+05:30) Maven home: /usr/lib/maven/apache-maven-3.5.4 Java version: 1.8.0_181, vendor: Oracle Corporation, runtime: /usr/lib/jvm/jdk1.8.0_181/jre Default locale: en_IN, platform encoding: UTF-8 OS name: "linux", version: "4.15.0-20-generic", arch: "amd64", family: "unix" Regards, Amey On Mon, Oct 1, 2018 at 6:33 PM Rob Tompkins wrote: > We have fixed quite a few bugs and added some significant enhancements > since Apache Commons Text 1.4 was released, so I would like to release > Apache Commons Text 1.5. > > Apache Commons Text 1.5 RC3 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/text/1.5-RC3 (svn > revision 29819) > > The Git tag commons-text-1.5-RC3 commit for this RC is > 4736b16d0e644289f3106275ebb1315750234e40 which you can browse here: > > https://git-wip-us.apache.org/repos/asf?p=commons-text.git;a=tag;h=refs/tags/commons-text-1.5-RC3 > > Maven artifacts are here: > > https://repository.apache.org/content/repositories/orgapachecommons-1386/org/apache/commons/commons-text/1.5/ > > These are the Maven artifacts and their hashes in Nexus: > > #Nexus SHA-1s > commons-text-1.5.pom=c2e89b076b2521ebc904a4880cf6338b59c2ac79 > commons-text-1.5-sources.jar=3f34009d1d7bd216d7af5da542273f81950fdd7c > commons-text-1.5.jar=e9054ac321b9240440462532991c1d29d517c82d > commons-text-1.5-tests.jar=e289230025ea112af417e852c6ea483d2fc26d40 > commons-text-1.5-test-sources.jar=53dcd066340b7ea678f14b4a8f9b8c9713581b46 > commons-text-1.5-javadoc.jar=aecce693e827b974dfff526c84571d65cb8bfd35 > > #Release SHA-256s > #Mon Oct 01 08:52:13 EDT 2018 > > commons-text-1.5-src-tar.gz=e74197b63f2fdb82d3eb813f348b1fa736bcce084e580f9768aa127acbfa6194 > > commons-text-1.5-javadoc-javadoc=c7eb048768a67faa37ceccd4f049cf4d618c57941a6f46435e9928019feaa8a7 > > commons-text-1.5-src-zip=3a88a20050e4a4f8033ee35cc25e59db86de6c0c7597427df3615c986cc1cf80 > > commons-text-1.5-bin-tar.gz=a62724a89014d1ae2460d3699d99469391db4db2b39928398304deb49adc4b33 > > commons-text-1.5-tests-test-jar=34aecf32ca739bc8a74e80ea4185cbb83b61793443ccb7b1c3e23486dc1853e1 > > commons-text-1.5-bin-zip=447d99d56a3cbb366ac345ed9fe640f88f6258db0c198018d4b552c4f9bfe0a4 > > commons-text-1.5-test-sources-java-source=c905aff4cb65ea6b5ba15b9066b0b0760bfe12f7420fd5909970cee7369fc813 > > commons-text-1.5-sources-java-source=00c37e139210b2bf41a2bd32fdf58c3a74c85303a7dbfc54db5983a48d43bc44 > > I have tested this with 'mvn clean test package site' using: > Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; > 2018-06-17T14:33:14-04:00) > Maven home: /usr/local/Cellar/maven/3.5.4/libexec > Java version: 10.0.2, vendor: Oracle Corporation, runtime: > /Library/Java/JavaVirtualMachines/jdk-10.0.2.jdk/Contents/Home > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "10.14", arch: "x86_64", family: "mac" > > Details of changes since 1.4 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/text/1.5-RC3/RELEASE-NOTES.txt > > https://dist.apache.org/repos/dist/dev/commons/text/1.5-RC3/site/changes-report.html > > Site: > https://dist.apache.org/repos/dist/dev/commons/text/1.5-RC3/site > (note some *relative* links are broken and the 1.5 directories are not > yet created - these will be OK once the site is deployed.) > > CLIRR Report (compared to 1.4): > > https://dist.apache.org/repos/dist/dev/commons/text/1.5-RC3/site/clirr-report.html > > JApiCmp Report (compared to 1.4): > > https://dist.apache.org/repos/dist/dev/commons/text/1.5-RC3/site/japicmp.html > > RAT Report: > > https://dist.apache.org/repos/dist/dev/commons/text/1.5-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 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, > > Rob Tompkins, > Release Manager (using key B6E73D84EA4FCC47166087253FAAD2CD5ECBB314) > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Statistics] Preferred name of the Jira project? (Was: [All] New git repository)
+1, STATISTICS. Regards, Amey On Thu, Jan 11, 2018, 5:42 AM Gilles <gil...@harfang.homelinux.org> wrote: > Hi. > > The preferred name of the component was "Commons Statistics". > What shall be the preferred name of the Jira project's "key" > (maximal length is 10 characters)? > > Regards, > Gilles > > P.S. My choice is "STATISTICS". > > On Wed, 03 Jan 2018 02:26:02 +0100, Gilles wrote: > > On Tue, 2 Jan 2018 11:13:00 -0500, Rob Tompkins wrote: > >>> On Jan 2, 2018, at 11:11 AM, Gary Gregory <garydgreg...@gmail.com> > >>> wrote: > >>> > >>> +1 I like the full name best: Commons Statistics. > > > > Repository created: > > https://git-wip-us.apache.org/repos/asf/commons-statistics.git > > > > Gilles > > > >> > >> [...] > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [All] New git repository
How about Commons Statistics ?, Sounds descriptive. Regards, Amey On Tue, Jan 2, 2018, 4:55 PM Gilles <gil...@harfang.homelinux.org> wrote: > Hi. > > I'm about to ask INFRA to create the usual tools (git, > JIRA, github, ...) for a new component: "Commons Stat". > > Is the name "Stat" OK for everybody? > > Regards, > Gilles > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [VOTE] Release Commons Text 1.2 based on RC1
Checked RC1, and here is my +1 (non-binding). 1. Build and Tests looks good. 2. Clirr looks good. 3. Rat is good. 4. Findbug looks good. 5. Checkstyle is good. 6. Hashes looks good. 7. Site looks good. Checked on :- Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T22:11:47+05:30) Maven home: /opt/apache/maven Java version: 1.8.0_111, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-8-oracle/jre Default locale: en_IN, platform encoding: UTF-8 OS name: "linux", version: "4.4.0-31-generic", arch: "amd64", family: "unix" Regards, Amey On Sat, Dec 9, 2017 at 9:46 AM, Rob Tompkins <chtom...@apache.org> wrote: > Hello all, > > This is a [VOTE] for releasing Apache Commons Text 1.2 (from RC1). > > Tag name: >commons-text-1.2-RC1 (signature can be checked from git using 'git tag > -v') > > Tag URL: >https://git-wip-us.apache.org/repos/asf?p=commons-text.git;a=commit;h= > 44a9f06abfbe898361bd2b486f786b22329face6 > > Commit ID the tag points at: >44a9f06abfbe898361bd2b486f786b22329face6 > > Site: >http://home.apache.org/~chtompki/commons-text-1.2-RC1 > > Distribution files (committed at revision 23484): >https://dist.apache.org/repos/dist/dev/commons/text/ > > Distribution files hashes (SHA1): >commons-text-1.2-bin.tar.gz >(SHA1: 180743785d360a22b56732869949b825e099791f) >commons-text-1.2-bin.zip >(SHA1: be2cd9803a5bc777c1b70c187321a579dc3d987d) >commons-text-1.2-src.tar.gz >(SHA1: 53c1226c37d55947383b2e30916e4ddaabee9a43) >commons-text-1.2-src.zip >(SHA1: 73989414ca74b0a44c0ac972e88cc4f1e0249fc7) > > These are the Maven artifacts and their hashes: >commons-text-1.2-javadoc.jar >(SHA1: e089747659cca1d18dfd7afe7fece4a1b1ffa6f5) >commons-text-1.2-sources.jar >(SHA1: 679282ee0f6f2b236f58a7a1dc8395861ad9fd97) >commons-text-1.2-test-sources.jar >(SHA1: 5128e2e681a640007a98509bffdddb61761c34b4) >commons-text-1.2-tests.jar >(SHA1: d735bd44b95df76cea4208d61dc15f45934da3ad) >commons-text-1.2.jar >(SHA1: 74acdec7237f576c4803fff0c1008ab8a3808b2b) >commons-text-1.2.pom >(SHA1: ad42c02430f03b89bec22c67710b43da77b1af72) > > KEYS file to check signatures: >http://www.apache.org/dist/commons/KEYS > > Maven artifacts: >https://repository.apache.org/content/repositories/ > orgapachecommons-1296 > > Please select one of the following options[1]: > [ ] +1 Release it. > [ ] +0 Go ahead; I don't care. > [ ] -0 There are a few minor glitches: ... > [ ] -1 No, do not release it because ... > > This vote will be open at least 72 hours, i.e. until > 2017-12-12T05:00:00Z > (this is UTC time). > > > Cheers, > -Rob > - > 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][Math] New component: "Commons Geometry"?
On Fri, Dec 1, 2017 at 7:23 PM, Amey Jadiye <ameyjad...@gmail.com> wrote: > > > On Fri, Dec 1, 2017 at 6:56 PM, Gilles <gil...@harfang.homelinux.org> > wrote: > >> Hello Amey. > > > Hi Gilles, > >> >> >> On Thu, 30 Nov 2017 23:45:45 +0530, Amey Jadiye wrote: >> >>> Pardon me for pulling this thread up again, I havent read anything about >>> "Commons Geometry" since long >>> >> >> Thanks for your renewed interest. >> >> (or may be I missed any other disscussion? ). >>> >> >> Probably not. >> >> is someone working on this ? >>> >> >> It would be a surprise. >> >> what is the final decision ? >>> >> >> There hasn't been any progress towards a decision. >> > > I'm not sure if "Lazy Consensus" works in these matters ? better take help > of it, its fast and easy. > > >> There isn't even a consensus on one of the central tenets of >> Apache ("Those who do the work..."): how sad/strange (?). >> >> I'm having good >>> amount of time to spend on this now, appreciate If someone direct me to >>> correct disscussion thread >>> >> >> IIRC, the one below is where we left off... >> >> I think I can help here. >>> >> >> Thanks for the offer! >> >> It took me half hour to read all old mails but dont see final verdict, >>> though I was in favour with Maven modules but after reading all again I >>> think Gilles approch is more practicle here and If no one is working I >>> can >>> submit something to review. >>> >> >> IMHO, the priority would be to review the status of "Numbers" >> (i.e. what is preventing a first release?). >> > > Ok, If commons number is priority let me check that first, I will chime in > here after that release. > last numbers release I see on 22/4/17, > apologies, that date belongs to site publish and SNAPSHOT, not the alpha release. and total open jiras are 18, what are min expectation here ? > I will open another thread If want advise., let this thread alive for > o.a.c.geometry. > > Regards, > Amey > > >> Best regards, >> Gilles >> >> >> >> Regards, >>> Amey >>> >>> On Wed, Sep 13, 2017 at 4:44 AM, Gilles <gil...@harfang.homelinux.org> >>> wrote: >>> >>> On Tue, 12 Sep 2017 13:07:24 +0200, Jochen Wiedmann wrote: >>>> >>>> On Sat, Sep 2, 2017 at 12:50 AM, Gilles <gil...@harfang.homelinux.org> >>>>> wrote: >>>>> >>>>> Because of "Commons" rules, it is not "equivalent": There was >>>>> >>>>>> a long thread concluding that all modules must be released >>>>>> _together_, and with the same top-level package name and version >>>>>> number. >>>>>> It is very "maintainer(s)-unfriendly" because of the quite >>>>>> different subject matters that coexist in CM. >>>>>> >>>>>> >>>>> I wouldn't count that rule "*all* modules must be released" as a >>>>> mantra: >>>>> >>>>> >>>> I found the idea attractive, but Stian (link to older discussion >>>> in a previous post) advised that maven would not easily "support" >>>> it. >>>> >>>> Has that changed since the discussion took place (10 months ago)? >>>> >>>> a) In case of an emergency release (fixing a CVE, for example), I'd >>>> >>>>> clearly consider pushing out the module as more important than waiting >>>>> for a full release. (Of course, one must be careful to maintain >>>>> compatibility when pushing out just a module, but that goes without >>>>> saying.) >>>>> b) I'd like to hear others experiences on that topic (maybe VFS). >>>>> Anyways, my personal experiences with Rat are clear: Releasing *all* >>>>> together is causing nothing but pain, and tends to defer releases >>>>> indefinitely. OTOH, releasing a submodule can be done at all times, >>>>> and without overly much preparation. >>>>> >>>>> In conclusion, I'd definitely support the release of a single >>>>> submodule, if the need would arise. >>>>> >>>>> >>>> How can one reconcile what you say here with wh
Re: [All][Math] New component: "Commons Geometry"?
On Fri, Dec 1, 2017 at 6:56 PM, Gilles <gil...@harfang.homelinux.org> wrote: > Hello Amey. Hi Gilles, > > > On Thu, 30 Nov 2017 23:45:45 +0530, Amey Jadiye wrote: > >> Pardon me for pulling this thread up again, I havent read anything about >> "Commons Geometry" since long >> > > Thanks for your renewed interest. > > (or may be I missed any other disscussion? ). >> > > Probably not. > > is someone working on this ? >> > > It would be a surprise. > > what is the final decision ? >> > > There hasn't been any progress towards a decision. > I'm not sure if "Lazy Consensus" works in these matters ? better take help of it, its fast and easy. > There isn't even a consensus on one of the central tenets of > Apache ("Those who do the work..."): how sad/strange (?). > > I'm having good >> amount of time to spend on this now, appreciate If someone direct me to >> correct disscussion thread >> > > IIRC, the one below is where we left off... > > I think I can help here. >> > > Thanks for the offer! > > It took me half hour to read all old mails but dont see final verdict, >> though I was in favour with Maven modules but after reading all again I >> think Gilles approch is more practicle here and If no one is working I can >> submit something to review. >> > > IMHO, the priority would be to review the status of "Numbers" > (i.e. what is preventing a first release?). > Ok, If commons number is priority let me check that first, I will chime in here after that release. last numbers release I see on 22/4/17, and total open jiras are 18, what are min expectation here ? I will open another thread If want advise., let this thread alive for o.a.c.geometry. Regards, Amey > Best regards, > Gilles > > > > Regards, >> Amey >> >> On Wed, Sep 13, 2017 at 4:44 AM, Gilles <gil...@harfang.homelinux.org> >> wrote: >> >> On Tue, 12 Sep 2017 13:07:24 +0200, Jochen Wiedmann wrote: >>> >>> On Sat, Sep 2, 2017 at 12:50 AM, Gilles <gil...@harfang.homelinux.org> >>>> wrote: >>>> >>>> Because of "Commons" rules, it is not "equivalent": There was >>>> >>>>> a long thread concluding that all modules must be released >>>>> _together_, and with the same top-level package name and version >>>>> number. >>>>> It is very "maintainer(s)-unfriendly" because of the quite >>>>> different subject matters that coexist in CM. >>>>> >>>>> >>>> I wouldn't count that rule "*all* modules must be released" as a mantra: >>>> >>>> >>> I found the idea attractive, but Stian (link to older discussion >>> in a previous post) advised that maven would not easily "support" >>> it. >>> >>> Has that changed since the discussion took place (10 months ago)? >>> >>> a) In case of an emergency release (fixing a CVE, for example), I'd >>> >>>> clearly consider pushing out the module as more important than waiting >>>> for a full release. (Of course, one must be careful to maintain >>>> compatibility when pushing out just a module, but that goes without >>>> saying.) >>>> b) I'd like to hear others experiences on that topic (maybe VFS). >>>> Anyways, my personal experiences with Rat are clear: Releasing *all* >>>> together is causing nothing but pain, and tends to defer releases >>>> indefinitely. OTOH, releasing a submodule can be done at all times, >>>> and without overly much preparation. >>>> >>>> In conclusion, I'd definitely support the release of a single >>>> submodule, if the need would arise. >>>> >>>> >>> How can one reconcile what you say here with what was said in >>> that old thread? >>> >>> Would the PMC accept that a component contains independent modules >>> (where "independent" means that each module can have its own version >>> number, irrespective of the component's version)? >>> >>> Arguably (cf. thread referred to above), a "Commons" component >>> should be simple enough that multiple versions are not necessary. >>> [Chorus:] This is not the case with "Commons Math", hence separate >>> components for independent contents (such as "Geometry", "RNG", >>> "Numbers" and "SigProc") is the simplest solution. >>> >>> Gilles >>> >>> Jochen >>> >>>> >>>> > > - > 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][Math] New component: "Commons Geometry"?
Pardon me for pulling this thread up again, I havent read anything about "Commons Geometry" since long (or may be I missed any other disscussion? ). is someone working on this ? what is the final decision ? I'm having good amount of time to spend on this now, appreciate If someone direct me to correct disscussion thread I think I can help here. It took me half hour to read all old mails but dont see final verdict, though I was in favour with Maven modules but after reading all again I think Gilles approch is more practicle here and If no one is working I can submit something to review. Regards, Amey On Wed, Sep 13, 2017 at 4:44 AM, Gilles <gil...@harfang.homelinux.org> wrote: > On Tue, 12 Sep 2017 13:07:24 +0200, Jochen Wiedmann wrote: > >> On Sat, Sep 2, 2017 at 12:50 AM, Gilles <gil...@harfang.homelinux.org> >> wrote: >> >> Because of "Commons" rules, it is not "equivalent": There was >>> a long thread concluding that all modules must be released >>> _together_, and with the same top-level package name and version >>> number. >>> It is very "maintainer(s)-unfriendly" because of the quite >>> different subject matters that coexist in CM. >>> >> >> I wouldn't count that rule "*all* modules must be released" as a mantra: >> > > I found the idea attractive, but Stian (link to older discussion > in a previous post) advised that maven would not easily "support" > it. > > Has that changed since the discussion took place (10 months ago)? > > a) In case of an emergency release (fixing a CVE, for example), I'd >> clearly consider pushing out the module as more important than waiting >> for a full release. (Of course, one must be careful to maintain >> compatibility when pushing out just a module, but that goes without >> saying.) >> b) I'd like to hear others experiences on that topic (maybe VFS). >> Anyways, my personal experiences with Rat are clear: Releasing *all* >> together is causing nothing but pain, and tends to defer releases >> indefinitely. OTOH, releasing a submodule can be done at all times, >> and without overly much preparation. >> >> In conclusion, I'd definitely support the release of a single >> submodule, if the need would arise. >> > > How can one reconcile what you say here with what was said in > that old thread? > > Would the PMC accept that a component contains independent modules > (where "independent" means that each module can have its own version > number, irrespective of the component's version)? > > Arguably (cf. thread referred to above), a "Commons" component > should be simple enough that multiple versions are not necessary. > [Chorus:] This is not the case with "Commons Math", hence separate > components for independent contents (such as "Geometry", "RNG", > "Numbers" and "SigProc") is the simplest solution. > > Gilles > > Jochen >> > > > - > 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: [lang][text] TEXT-101: RandomStringUtils
No worries Pascal, it was good experience to change core logic of RandomStringUtils, also I'm free to pickup something else now ;-) Regards, Amey On Mon, Oct 2, 2017, 3:49 PM Pascal Schumacher <pascalschumac...@gmx.net> wrote: > Sorry about wasting your work porting RandomStringUtils to commons-text. :( > > Sorry, > Pascal > > Am 29.09.2017 um 17:18 schrieb Amey Jadiye: > > Okey, no problem folks. I'm going to close my PR. also we might need to > > release lang-3.6.1 for undoing deprecation of RandomStringUtils if > > lang-3.7 is far. > > > > Regards, > > Amey > > > > On Fri, Sep 29, 2017 at 1:41 PM, Pascal Schumacher < > pascalschumac...@gmx.net > >> wrote: > >> After thinking more about it, I came the conclusion that > RandomStringUtils > >> fits into [lang], so I'm for option (b). > >> > >> Cheers, > >> Pascal > >> > >> > >> Am 28.09.2017 um 23:26 schrieb Rob Tompkins: > >> > >>> Options: > >>> > >>> (a) leave RandomStringUtils deprecated in [lang] and pull in Amey’s > pull > >>> request moving it into [text]. > >>> (b) undeprecate it in [lang]. > >>> > >>> The question is where should it reside? Does it fit as a general java > >>> Lang extension or is it more focused on text? > >>> > >>> I’m in the middle here. Note also that we had some users ask why it had > >>> been deprecated with no alternative. > >>> > >>> Amey - keep me honest here. I don’t want to overlook anything. > >>> > >>> -Rob > >>> > >>> On Sep 28, 2017, at 5:13 PM, Gary Gregory <garydgreg...@gmail.com> > wrote: > >>>> Can someone summarize what our options are here please? I'd rather > see it > >>>> fresh than chasing links in mailing list archives and try to un-nest > all > >>>> the nesting... ;-) > >>>> > >>>> Gary > >>>> > >>>> > >>>> > >>>> On Wed, Sep 27, 2017 at 1:01 PM, Rob Tompkins < > notificati...@github.com> > >>>> wrote: > >>>> > >>>> As I'm pulling this in this crosses my mind: > >>>>> Wait I'm curious here. Weren't folks leaning towards keeping > >>>>> RandomStringUtils in [lang]? > >>>>> > >>>>> The thread in question is this one: http://markmail.org/message/ > >>>>> 5tblwhldrwsbfdym > >>>>> > >>>>> It feels like @britter <https://github.com/britter>, > @PascalSchumacher > >>>>> <https://github.com/pascalschumacher>, and @garydgregory > >>>>> <https://github.com/garydgregory> were all leaning towards the > [lang] > >>>>> option. If that's the case we should probably go with that. > >>>>> > >>>>> — > >>>>> You are receiving this because you were mentioned. > >>>>> Reply to this email directly, view it on GitHub > >>>>> < > https://github.com/apache/commons-text/pull/62#issuecomment-332622968 > >>>>>> , > >>>>> or mute the thread > >>>>> <https://github.com/notifications/unsubscribe-auth/ABIfN0WS8 > >>>>> OJew2JaosTy8DEkFh8bqjU8ks5smpuVgaJpZM4PO83B> > >>>>> . > >>>>> > >>>>> - > >>> 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: [lang][text] TEXT-101: RandomStringUtils
Okey, no problem folks. I'm going to close my PR. also we might need to release lang-3.6.1 for undoing deprecation of RandomStringUtils if lang-3.7 is far. Regards, Amey On Fri, Sep 29, 2017 at 1:41 PM, Pascal Schumacher <pascalschumac...@gmx.net > wrote: > After thinking more about it, I came the conclusion that RandomStringUtils > fits into [lang], so I'm for option (b). > > Cheers, > Pascal > > > Am 28.09.2017 um 23:26 schrieb Rob Tompkins: > >> Options: >> >> (a) leave RandomStringUtils deprecated in [lang] and pull in Amey’s pull >> request moving it into [text]. >> (b) undeprecate it in [lang]. >> >> The question is where should it reside? Does it fit as a general java >> Lang extension or is it more focused on text? >> >> I’m in the middle here. Note also that we had some users ask why it had >> been deprecated with no alternative. >> >> Amey - keep me honest here. I don’t want to overlook anything. >> >> -Rob >> >> On Sep 28, 2017, at 5:13 PM, Gary Gregory <garydgreg...@gmail.com> wrote: >>> >>> Can someone summarize what our options are here please? I'd rather see it >>> fresh than chasing links in mailing list archives and try to un-nest all >>> the nesting... ;-) >>> >>> Gary >>> >>> >>> >>> On Wed, Sep 27, 2017 at 1:01 PM, Rob Tompkins <notificati...@github.com> >>> wrote: >>> >>> As I'm pulling this in this crosses my mind: >>>> >>>> Wait I'm curious here. Weren't folks leaning towards keeping >>>> RandomStringUtils in [lang]? >>>> >>>> The thread in question is this one: http://markmail.org/message/ >>>> 5tblwhldrwsbfdym >>>> >>>> It feels like @britter <https://github.com/britter>, @PascalSchumacher >>>> <https://github.com/pascalschumacher>, and @garydgregory >>>> <https://github.com/garydgregory> were all leaning towards the [lang] >>>> option. If that's the case we should probably go with that. >>>> >>>> — >>>> You are receiving this because you were mentioned. >>>> Reply to this email directly, view it on GitHub >>>> <https://github.com/apache/commons-text/pull/62#issuecomment-332622968 >>>> >, >>>> or mute the thread >>>> <https://github.com/notifications/unsubscribe-auth/ABIfN0WS8 >>>> OJew2JaosTy8DEkFh8bqjU8ks5smpuVgaJpZM4PO83B> >>>> . >>>> >>>> - >> 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: [apache/commons-text] [TEXT-102] StrLookup.resourceBundleLookup(ResourceBundle). Make new (0b06169)
I usually keep the practice of running just `mvn` (which indeed run clean verify apache-rat:check clirr:check checkstyle:check findbugs:check javadoc:javadoc) and if that's fine my submitted PR is always and 100% looks green. Regards, Amey On Sat, Sep 23, 2017 at 9:06 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > Amazing what happens when I actually run the Checkstyle plugin myself ;-) > > Gary > > On Sat, Sep 23, 2017 at 9:34 AM, Pascal Schumacher < > pascalschumac...@gmx.net > > wrote: > > > Thanks! :) > > > > Am 23.09.2017 um 16:13 schrieb Gary Gregory: > > > >> Back to green! :-) https://travis-ci.org/apache/commons-text > >> > >> Gary > >> > >> On Sat, Sep 23, 2017 at 2:15 AM, Pascal Schumacher < > >> pascalschumac...@gmx.net > >> > >>> wrote: > >>> Thank you very much. Sadly there are still two violations: > >>> > >>> [INFO] There are 2 checkstyle errors. > >>> [ERROR] StrLookup.java[179] (design) FinalClass: Class > >>> ResourceBundleLookup should be declared as final. > >>> [ERROR] StrLookup.java[181:9] (javadoc) JavadocVariable: Missing a > >>> Javadoc > >>> comment. > >>> > >>> see: https://travis-ci.org/apache/commons-text/jobs/278794812 > >>> > >>> Am 22.09.2017 um 23:50 schrieb Gary Gregory: > >>> > >>> Fixed in git master. > >>>> > >>>> Gary > >>>> > >>>> On Fri, Sep 22, 2017 at 3:35 PM, Pascal Schumacher < > >>>> notificati...@github.com > >>>> > >>>> wrote: > >>>>> Builds on travis fail: > >>>>> > >>>>> [INFO] There are 6 checkstyle errors. > >>>>> [ERROR] StrLookup.java[119] (regexp) RegexpSingleline: Line has > >>>>> trailing > >>>>> spaces. > >>>>> [ERROR] StrLookup.java[125] (regexp) RegexpSingleline: Line has > >>>>> trailing > >>>>> spaces. > >>>>> [ERROR] StrLookup.java[181:9] (javadoc) JavadocVariable: Missing a > >>>>> Javadoc comment. > >>>>> [ERROR] StrLookup.java[183:9] (javadoc) JavadocMethod: Missing a > >>>>> Javadoc > >>>>> comment. > >>>>> [ERROR] StrLookup.java[194] (regexp) RegexpSingleline: Line has > >>>>> trailing > >>>>> spaces. > >>>>> [ERROR] StrLookup.java[199] (regexp) RegexpSingleline: Line has > >>>>> trailing > >>>>> spaces. > >>>>> > >>>>> see e.g.: https://travis-ci.org/apache/commons-text/jobs/278728858 > >>>>> > >>>>> — > >>>>> You are receiving this because you authored the thread. > >>>>> Reply to this email directly, view it on GitHub > >>>>> <https://github.com/apache/commons-text/commit/0b061698f7b8d > >>>>> c0665804fadcfb6f9f37048efee#commitcomment-24498832>, > >>>>> or mute the thread > >>>>> <https://github.com/notifications/unsubscribe-auth/ABIfNyqCj > >>>>> e4hkCkwblS9o6g2rL4hJM8Dks5slCgagaJpZM4PhRMH> > >>>>> . > >>>>> > >>>>> > >>>>> > - > >>> 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: [text] Release 1.2
I wish to see TEXT-101 part of release which will settle down many enquiries from user-dl about RandomStringUtils without releasing commons-lang 3.6.1. I have open PR for it, may be you or Rob have to check that. Regards, Amey On Sat, Sep 23, 2017 at 8:53 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > Hi All: > > I'd like to see Apache Commons Text 1.2 out. We have a stack of changes [1] > waiting. > > - If you'd like to volunteer to RM, please do so :-) > - If you have some fixes, consider putting them in now. > - I might have the time to RM an RC this weekend, not 100% sure on my > avail. > > Gary > > [1] From changes.xml: > > > RandomStringGenerator able to pass multiple ranges to > .withinRange() > Deprecate isDelimiter and use HashSets for delimiter checks > WordUtils.initials support for UTF-16 surrogate pairs > WordUtils should treat an empty delimiter array as no > delimiters > Update RandomStringGenerator to accept a list of valid > characters > Add > CharacterPredicates for ASCII letters (uppercase/lowercase) and arabic > numerals > Added CaseUtils class with camel case conversion support > dev="pschumacher">RandomStringGenerator should be able to generate a > String > with a random length > Update > commons-lang dependency to version 3.6 > Document that commons-csv should be used in preference to > CsvTranslators > dev="kinow">NumericEntityUnescaper.options - fix TODO > dev="djones">RandomStringGenerator claims to be immutable, but > isn't > Add > StrLookup.resourceBundleLookup(ResourceBundle) > > -- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [text] license header
Ah, my bad actually after your commit for TEXT-102 Travis was failed [1]. so seems we are good here. [1] https://travis-ci.org/apache/commons-text/builds/278697845 Regards, Amey On Fri, Sep 22, 2017 at 11:41 PM, Amey Jadiye <ameyjad...@gmail.com> wrote: > Its already there [1] and fails if something is not correct in *main* but > I guess it doesn't check anything for test resources and test java files. > thats why build was passing till date. > > > [1]. https://github.com/apache/commons-text/blob/master/pom.xml > > Regards, > Amey > > On Fri, Sep 22, 2017 at 10:58 PM, Gary Gregory <garydgreg...@gmail.com> > wrote: > >> Hm, I guess we could add 'apache-rat:check' and 'clirr:check' to the >> Travis >> and Jenkins builds. >> >> Gary >> >> On Fri, Sep 22, 2017 at 11:26 AM, Gary Gregory <garydgreg...@gmail.com> >> wrote: >> >> > Good catch and thank you. >> > >> > I wish we could set up Maven to run the RAT check and fail a local build >> > if a header is missing. >> > >> > Gary >> > >> > >> > On Fri, Sep 22, 2017 at 11:24 AM, <chtom...@apache.org> wrote: >> > >> >> Repository: commons-text >> >> Updated Branches: >> >> refs/heads/master 3292f74df -> 8cdbbd34b >> >> >> >> >> >> license header >> >> >> >> >> >> Project: http://git-wip-us.apache.org/repos/asf/commons-text/repo >> >> Commit: http://git-wip-us.apache.org/repos/asf/commons-text/commit/8 >> >> cdbbd34 >> >> Tree: http://git-wip-us.apache.org/repos/asf/commons-text/tree/8cd >> bbd34 >> >> Diff: http://git-wip-us.apache.org/repos/asf/commons-text/diff/8cd >> bbd34 >> >> >> >> Branch: refs/heads/master >> >> Commit: 8cdbbd34be793c828fb2000a3d75661aacae7dfc >> >> Parents: 3292f74 >> >> Author: Rob Tompkins <chtom...@gmail.com> >> >> Authored: Fri Sep 22 13:24:00 2017 -0400 >> >> Committer: Rob Tompkins <chtom...@gmail.com> >> >> Committed: Fri Sep 22 13:24:00 2017 -0400 >> >> >> >> -- >> >> .../resources/testResourceBundleLookup.properties| 15 >> >> +++ >> >> 1 file changed, 15 insertions(+) >> >> -- >> >> >> >> >> >> http://git-wip-us.apache.org/repos/asf/commons-text/blob/8cd >> >> bbd34/src/test/resources/testResourceBundleLookup.properties >> >> -- >> >> diff --git a/src/test/resources/testResourceBundleLookup.properties >> >> b/src/test/resources/testResourceBundleLookup.properties >> >> index f1394e7..ea39746 100644 >> >> --- a/src/test/resources/testResourceBundleLookup.properties >> >> +++ b/src/test/resources/testResourceBundleLookup.properties >> >> @@ -1,2 +1,17 @@ >> >> +# Licensed to the Apache Software Foundation (ASF) under one or more >> >> +# contributor license agreements. See the NOTICE file distributed >> with >> >> +# this work for additional information regarding copyright ownership. >> >> +# The ASF licenses this file to You under the Apache License, Version >> 2.0 >> >> +# (the "License"); you may not use this file except in compliance with >> >> +# the License. You may obtain a copy of the License at >> >> +# >> >> +# http://www.apache.org/licenses/LICENSE-2.0 >> >> +# >> >> +# Unless required by applicable law or agreed to in writing, software >> >> +# distributed under the License is distributed on an "AS IS" BASIS, >> >> +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or >> >> implied. >> >> +# See the License for the specific language governing permissions and >> >> +# limitations under the License. >> >> + >> >> key = value >> >> number = 2 >> >> >> >> >> > >> > > > > -- > > - > > 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: [text] license header
Its already there [1] and fails if something is not correct in *main* but I guess it doesn't check anything for test resources and test java files. thats why build was passing till date. [1]. https://github.com/apache/commons-text/blob/master/pom.xml Regards, Amey On Fri, Sep 22, 2017 at 10:58 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > Hm, I guess we could add 'apache-rat:check' and 'clirr:check' to the Travis > and Jenkins builds. > > Gary > > On Fri, Sep 22, 2017 at 11:26 AM, Gary Gregory <garydgreg...@gmail.com> > wrote: > > > Good catch and thank you. > > > > I wish we could set up Maven to run the RAT check and fail a local build > > if a header is missing. > > > > Gary > > > > > > On Fri, Sep 22, 2017 at 11:24 AM, <chtom...@apache.org> wrote: > > > >> Repository: commons-text > >> Updated Branches: > >> refs/heads/master 3292f74df -> 8cdbbd34b > >> > >> > >> license header > >> > >> > >> Project: http://git-wip-us.apache.org/repos/asf/commons-text/repo > >> Commit: http://git-wip-us.apache.org/repos/asf/commons-text/commit/8 > >> cdbbd34 > >> Tree: http://git-wip-us.apache.org/repos/asf/commons-text/tree/8cdbbd34 > >> Diff: http://git-wip-us.apache.org/repos/asf/commons-text/diff/8cdbbd34 > >> > >> Branch: refs/heads/master > >> Commit: 8cdbbd34be793c828fb2000a3d75661aacae7dfc > >> Parents: 3292f74 > >> Author: Rob Tompkins <chtom...@gmail.com> > >> Authored: Fri Sep 22 13:24:00 2017 -0400 > >> Committer: Rob Tompkins <chtom...@gmail.com> > >> Committed: Fri Sep 22 13:24:00 2017 -0400 > >> > >> -- > >> .../resources/testResourceBundleLookup.properties| 15 > >> +++ > >> 1 file changed, 15 insertions(+) > >> -- > >> > >> > >> http://git-wip-us.apache.org/repos/asf/commons-text/blob/8cd > >> bbd34/src/test/resources/testResourceBundleLookup.properties > >> -- > >> diff --git a/src/test/resources/testResourceBundleLookup.properties > >> b/src/test/resources/testResourceBundleLookup.properties > >> index f1394e7..ea39746 100644 > >> --- a/src/test/resources/testResourceBundleLookup.properties > >> +++ b/src/test/resources/testResourceBundleLookup.properties > >> @@ -1,2 +1,17 @@ > >> +# Licensed to the Apache Software Foundation (ASF) under one or more > >> +# contributor license agreements. See the NOTICE file distributed with > >> +# this work for additional information regarding copyright ownership. > >> +# The ASF licenses this file to You under the Apache License, Version > 2.0 > >> +# (the "License"); you may not use this file except in compliance with > >> +# the License. You may obtain a copy of the License at > >> +# > >> +# http://www.apache.org/licenses/LICENSE-2.0 > >> +# > >> +# Unless required by applicable law or agreed to in writing, software > >> +# distributed under the License is distributed on an "AS IS" BASIS, > >> +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or > >> implied. > >> +# See the License for the specific language governing permissions and > >> +# limitations under the License. > >> + > >> key = value > >> number = 2 > >> > >> > > > -- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Javadoc.io - a new GitHub badge for our projects?
+1, LGTM. Regards, Amey On Mon, Sep 18, 2017, 3:24 PM Benedikt Ritter <brit...@apache.org> wrote: > Hi, > > I just became aware of https://javadoc.io/ <https://javadoc.io/> a > website which provides hosting for all javadocs on Maven Central. They also > provide badges for GitHub. Do we want to add this to our README.md files? > > Cheers, > Benedikt > >
Re: [numbers-complex] Checkstyle "unknown tag: if"
It is there https://github.com/apache/commons-numbers/tree/complex-dev Try : git fetch origin git checkout -t origin/complex-dev BTW, I did mvn site:run which runs fine and there is zero error under reports > Checkstyle. Also did `mvn clean verify checkstyle:check` which run clean, "zero errors" again, under complex-dev. I turned on failOnViolation and then as well its telling only 4 errors, but now showing it :( [ERROR] Failed to execute goal org.apache.maven.plugins:maven-checkstyle-plugin:2.17:check (default-cli) on project commons-numbers-parent: You have 4 Checkstyle violations. -> [Help 1] [ERROR] I don't see Initial issue of "unknown tag: if" though. amey@xps /tmp/commons-numbers $ mvn -v Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T22:11:47+05:30) Maven home: /opt/apache/maven Java version: 1.8.0_111, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-8-oracle/jre Default locale: en_IN, platform encoding: UTF-8 OS name: "linux", version: "4.4.0-31-generic", arch: "amd64", family: "unix" Regards, Amey On Wed, Sep 13, 2017 at 8:29 PM, Gilles <gil...@harfang.homelinux.org> wrote: > On Wed, 13 Sep 2017 16:35:38 +0200, Eric Barnhill wrote: > >> the branch is called complex-dev >> > > "git fetch --all" does not retrieve it. > > Should I issue another command? > > Thanks, > Gilles > > > >> On Wed, Sep 13, 2017 at 4:27 PM, Gilles <gil...@harfang.homelinux.org> >> wrote: >> >> On Wed, 13 Sep 2017 15:54:59 +0200, Eric Barnhill wrote: >>> >>> Running checkstyle on commons-numbers-complex, I get several >>>> >>>> unknown tag: if >>>> >>>> >>>>> >>>>> errors that predate me. >>>> >>>> Has there been a change in accepted style, so that these tags don't work >>>> anymore, but they once did? In which case I will replace them. >>>> >>>> >>> Running "mvn site" from "master" is successful. >>> >>> Somehow, I don't see the branch where you made all the developments... >>> >>> Regards >>> Gilles >>> >>> >>> Eric >>>> >>>> >>> > > - > 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: Moved RSU to Text [was] [LANG] Releasing 3.6.1
I'm fine with that, how about other people think about the change ? and one open question related to this in other mail thread. http://markmail.org/message/2o3v7qka742kc2rv Regards, Amey On Tue, Sep 12, 2017 at 8:35 PM, Rob Tompkins <chtom...@gmail.com> wrote: > > > > On Sep 12, 2017, at 12:38 AM, Amey Jadiye <ameyjad...@gmail.com> wrote: > > > > Hello Rob, > > I'm going to be away from my computer until Friday. I'll give it a look > then if that's alright with you. > > Cheers, > -Rob > > > > I have submitted pull req. let me know if below action plan looks good. > > > > * RandomStringGenerator in commons-text > > * new RandomStringUtils in commons-text with different package using > > RandomStringGenerator > > * Mark RandomStringUtils in commons-lang as deprecated > > * release commons-text 1.2 > > * release commons-lang 3.7 (doesn't matter ATM) > > * later remove RSU from commons-lang from Commons lang 4.0 > > > > Regards, > > Amey > > > >> On Wed, Sep 6, 2017, 4:43 PM Rob Tompkins <chtom...@gmail.com> wrote: > >> > >> > >>> On Sep 6, 2017, at 7:05 AM, Gilles <gil...@harfang.homelinux.org> > wrote: > >>> > >>> On Wed, 6 Sep 2017 06:55:49 -0400, Rob Tompkins wrote: > >>>>> On Sep 6, 2017, at 3:34 AM, Amey Jadiye <ameyjad...@gmail.com> > wrote: > >>>>> > >>>>> Hi Rob, > >>>>> > >>>>> Looking at frequency I think more number of requests coming > >>>>> for RandomStringUtils for its simplicity. > >>>>> > >>>>> RandomStringGenerator is strong , flexible but one can't use it > >> quickly. > >>>>> Also I think this tool should belong in Commons text's arsenal. I'm > not > >>>>> only moving RandomStringUtils to text but changing its core logic > with > >>>>> using > >>>>> RandomStringGenerator which seems fair to me. So finally we should > >> release > >>>>> text-1.2 rather doing rollback of deprecation and release lang 3.6.1, > >> WDYT > >>>>> ? > >>>>> > >>>> > >>>> I definitely lean this direction, but if I recall correctly we drew > >>>> “line between [lang] and [text]” to be: a piece of functionality > >>>> should go in [lang] if the arbitrary java developer would probably > >>>> want it, whereas text is geared towards folks actually doing text > >>>> manipulation [1]. > >>>> > >>>> Personally I’m a +0 to +1 on doing this, but I wanted to gauge other > >>>> folks’ thoughts here because I feel like we’re in that grey area here. > >>>> That said, I’m perfectly willing to roll a 1.2 [text] release. > >>> > >>> "Grey area" should favour small components. > >> > >> Fair point. I take that to mean that you think that it should either go > >> into text to make lang smaller or its own component. > >> > >> I suppose because the generator lives in [text] that makes a good > argument > >> for [text]. > >> > >> More thoughts out there? > >> > >> -Rob > >> > >>> > >>> Gilles > >>> > >>>> > >>>> Cheers, > >>>> -Rob > >>>> > >>>> [1] http://markmail.org/message/a2urysnxvxihfoto > >>>> > >>>>> Regards, > >>>>> Amey > >>>>> > >>>>>> On Wed, Sep 6, 2017, 12:00 AM Rob Tompkins <chtom...@gmail.com> > wrote: > >>>>>> > >>>>>> > >>>>>>> On Sep 5, 2017, at 11:00 AM, Amey Jadiye <ameyjad...@gmail.com> > >> wrote: > >>>>>>> > >>>>>>> Hello Benedikt, > >>>>>>> > >>>>>>> How about we keep that deprecated in lang and release Text-1.2 ? > >>>>>> [snip] > >>>>>> > >>>>>> I’m on board with this if folks are complaining and the original > >> intent > >>>>>> was to deprecate things in [lang]. Why not roll forward as opposed > to > >>>>>> backwards? > >>>>>> > >>>>>> But, that opens the question: Is RandomStringUtils something that > most > >>>>>> folks would want (i.e. should it be in [lang] or [text])? I think > that > >>>>>> question is more the heart of the problem here. Either direction > seems > >>>>>> reasonable to me. > >>>>>> > >>>>>> Thoughts? > >>>>>> > >>>>>> -Rob > >>>>>> > >>> > >>> > >>> - > >>> 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: Moved RSU to Text [was] [LANG] Releasing 3.6.1
Hello Rob, I have submitted pull req. let me know if below action plan looks good. * RandomStringGenerator in commons-text * new RandomStringUtils in commons-text with different package using RandomStringGenerator * Mark RandomStringUtils in commons-lang as deprecated * release commons-text 1.2 * release commons-lang 3.7 (doesn't matter ATM) * later remove RSU from commons-lang from Commons lang 4.0 Regards, Amey On Wed, Sep 6, 2017, 4:43 PM Rob Tompkins <chtom...@gmail.com> wrote: > > > On Sep 6, 2017, at 7:05 AM, Gilles <gil...@harfang.homelinux.org> wrote: > > > > On Wed, 6 Sep 2017 06:55:49 -0400, Rob Tompkins wrote: > >>> On Sep 6, 2017, at 3:34 AM, Amey Jadiye <ameyjad...@gmail.com> wrote: > >>> > >>> Hi Rob, > >>> > >>> Looking at frequency I think more number of requests coming > >>> for RandomStringUtils for its simplicity. > >>> > >>> RandomStringGenerator is strong , flexible but one can't use it > quickly. > >>> Also I think this tool should belong in Commons text's arsenal. I'm not > >>> only moving RandomStringUtils to text but changing its core logic with > >>> using > >>> RandomStringGenerator which seems fair to me. So finally we should > release > >>> text-1.2 rather doing rollback of deprecation and release lang 3.6.1, > WDYT > >>> ? > >>> > >> > >> I definitely lean this direction, but if I recall correctly we drew > >> “line between [lang] and [text]” to be: a piece of functionality > >> should go in [lang] if the arbitrary java developer would probably > >> want it, whereas text is geared towards folks actually doing text > >> manipulation [1]. > >> > >> Personally I’m a +0 to +1 on doing this, but I wanted to gauge other > >> folks’ thoughts here because I feel like we’re in that grey area here. > >> That said, I’m perfectly willing to roll a 1.2 [text] release. > > > > "Grey area" should favour small components. > > Fair point. I take that to mean that you think that it should either go > into text to make lang smaller or its own component. > > I suppose because the generator lives in [text] that makes a good argument > for [text]. > > More thoughts out there? > > -Rob > > > > > Gilles > > > >> > >> Cheers, > >> -Rob > >> > >> [1] http://markmail.org/message/a2urysnxvxihfoto > >> > >>> Regards, > >>> Amey > >>> > >>> On Wed, Sep 6, 2017, 12:00 AM Rob Tompkins <chtom...@gmail.com> wrote: > >>> > >>>> > >>>>> On Sep 5, 2017, at 11:00 AM, Amey Jadiye <ameyjad...@gmail.com> > wrote: > >>>>> > >>>>> Hello Benedikt, > >>>>> > >>>>> How about we keep that deprecated in lang and release Text-1.2 ? > >>>> [snip] > >>>> > >>>> I’m on board with this if folks are complaining and the original > intent > >>>> was to deprecate things in [lang]. Why not roll forward as opposed to > >>>> backwards? > >>>> > >>>> But, that opens the question: Is RandomStringUtils something that most > >>>> folks would want (i.e. should it be in [lang] or [text])? I think that > >>>> question is more the heart of the problem here. Either direction seems > >>>> reasonable to me. > >>>> > >>>> Thoughts? > >>>> > >>>> -Rob > >>>> > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [text] Invalid unicode sequences on .substring of RandomStringGenerator
Thanks much for checking this Bruno. On Mon, Sep 11, 2017 at 3:05 PM, Bruno P. Kinoshita < brunodepau...@yahoo.com.br.invalid> wrote: > Hi Amey, > > You created a byte array from the original string (which may contain > surrogate chars). But then you created a copy string with `final String > copy = new String(bytes, charset);`. There will be encoding to UTF-8, which > may fail to encode some values, leading to the error you reported I suspect. > > I did this purposefully for checking LANG-100 issue, issue was about the string conversion from UTF-16(default) to UTF-8 back and forth. My expectation was this test should pass clean. > If you try `final String copy = new String(bytes);` there will be still > encoding to the default system charset as well. > > So I think the safest is to compare codepoints. Perhaps with something > like this: > > @Test > public void testSubStringWithSurrogatePair() { > for (int j = 0; j < 10; j++) { > final int size = 5000;RandomStringGenerator > generator = new RandomStringGenerator.Builder().build(); > String orig = generator.generate(size).substring(0, 2500); > final String copy = new String(orig); > for (int i = 0; i < orig.length() && i < copy.length(); i++) > {final int o = orig.codePointAt(i);final > int c = copy.codePointAt(i); > assertEquals(String.format("Differs > where j = %d, i = %d, o = %d, and c = %d", j, i, o, c), o, c); > }} > } > > Running it 10 times, I was able to consistently reproduce the initial > issue. It would always fail, about 4 out of 10. I think [rng] or somewhere > in another commons component I kind of remember seeing unit tests for > random generated values using loops? But may be mistaken (I don't trust my > own memory). So feel free to leave that part out if you prefer. I tried the > code above with j going up to 1000. After a few seconds, the test passed > too. > yeah I did same kind of testing and found it happens intermittently, whenever surrogate pair comes on last position where I cut string, i.e. 0 to 2500, so if there is pair on 2500 it will be cut in half and issue comes which i found obvious now. And Yes I cant keep it as is for the sake of not introducing LANG-100 again in commons-text. > Doing `final String copy = new String(orig);` the value of the original > string is completely copied onto the new string. So comparing the > codepoints should do the trick. We may even want to add another assert > statement before the for loop to confirm both strings have the same length? > Whatever you suggested here work fine with no issues, even length is same, goal of doing this was to return exact length of string which asked by used. > Hope that helps,Bruno > > Now I want community advice that why the RandomStringGenerator's .generate(int count) method designed in such way that it will return given number of codepoints and not the actual length of String ? I'm ok with this approach as well but can we have one more .generate which can return the actual String of given length ? I found when I pass .50 it returns me ~70 length of string, as commons-dev its good but as application-dev its weird. Regards, Amey > > > > From: Amey Jadiye <ameyjad...@gmail.com> > To: Commons Developers List <dev@commons.apache.org> > Sent: Monday, 11 September 2017 12:15 AM > Subject: [text] Invalid unicode sequences on .substring of > RandomStringGenerator > > > > Hi Folks, > > > While working on RandomStringGenerator I found when I'm doing .substring on > > generated random string its failing intermittently with sequence of > > surrogate pair. > > same bug was raised in commons-lang > > https://issues.apache.org/jira/browse/LANG-100 > > > Is this possible bug with RandomStringGenerator ? or is this expected ? > > > @Test > > public void testSubStringWithSurrogatePair() { > > final int size = 5000; > > final Charset charset = Charset.forName("UTF-8"); > > RandomStringGenerator generator = new > > RandomStringGenerator.Builder().build(); > > String orig = generator.generate(size).substring(0,2500); > > > final byte[] bytes = orig.getBytes(charset); > > final String copy = new String(bytes, charset); > > > for (int i=0; i < orig.length() && i < copy.length(); i++) { > > final char o = orig.charAt(i); > > final char c = copy.charAt(i); > > assertEquals("differs at " + i + "(" + Intege
[text] Invalid unicode sequences on .substring of RandomStringGenerator
Hi Folks, While working on RandomStringGenerator I found when I'm doing .substring on generated random string its failing intermittently with sequence of surrogate pair. same bug was raised in commons-lang https://issues.apache.org/jira/browse/LANG-100 Is this possible bug with RandomStringGenerator ? or is this expected ? @Test public void testSubStringWithSurrogatePair() { final int size = 5000; final Charset charset = Charset.forName("UTF-8"); RandomStringGenerator generator = new RandomStringGenerator.Builder().build(); String orig = generator.generate(size).substring(0,2500); final byte[] bytes = orig.getBytes(charset); final String copy = new String(bytes, charset); for (int i=0; i < orig.length() && i < copy.length(); i++) { final char o = orig.charAt(i); final char c = copy.charAt(i); assertEquals("differs at " + i + "(" + Integer.toHexString(new Character(o).hashCode()) + "," + Integer.toHexString(new Character(c).hashCode()) + ")", o, c); } } Regards, Amey - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LANG] Releasing 3.6.1
Hi Rob, Looking at frequency I think more number of requests coming for RandomStringUtils for its simplicity. RandomStringGenerator is strong , flexible but one can't use it quickly. Also I think this tool should belong in Commons text's arsenal. I'm not only moving RandomStringUtils to text but changing its core logic with using RandomStringGenerator which seems fair to me. So finally we should release text-1.2 rather doing rollback of deprecation and release lang 3.6.1, WDYT ? Regards, Amey On Wed, Sep 6, 2017, 12:00 AM Rob Tompkins <chtom...@gmail.com> wrote: > > > On Sep 5, 2017, at 11:00 AM, Amey Jadiye <ameyjad...@gmail.com> wrote: > > > > Hello Benedikt, > > > > How about we keep that deprecated in lang and release Text-1.2 ? > [snip] > > I’m on board with this if folks are complaining and the original intent > was to deprecate things in [lang]. Why not roll forward as opposed to > backwards? > > But, that opens the question: Is RandomStringUtils something that most > folks would want (i.e. should it be in [lang] or [text])? I think that > question is more the heart of the problem here. Either direction seems > reasonable to me. > > Thoughts? > > -Rob > > > I will > > submit changes [1] related to this in fact i'm fixing couple of failing > > test cases ATM. If you are planning to release 3.6.1 just to remove > > deprecation and deprecate RandomStringUtils back in Lang - 3.7 I'm fine > > with that as well. > > > > [1]. https://issues.apache.org/jira/browse/TEXT-101 > > > > On Tue, Sep 5, 2017 at 10:47 AM, Benedikt Ritter <brit...@apache.org> > wrote: > > > >> Hi, > >> > >> since we’re getting more and more requests about the deprecation of > >> RandomStringUtils, I’m thinking about releasing the current state of the > >> master branch as 3.6.1. I may have time to push an RC sometime this > week. > >> So if you have some fixes you want to include, please do so now. > >> > >> Regards, > >> Benedikt > >> - > >> 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: [LANG] Releasing 3.6.1
Hello Benedikt, How about we keep that deprecated in lang and release Text-1.2 ? I will submit changes [1] related to this in fact i'm fixing couple of failing test cases ATM. If you are planning to release 3.6.1 just to remove deprecation and deprecate RandomStringUtils back in Lang - 3.7 I'm fine with that as well. [1]. https://issues.apache.org/jira/browse/TEXT-101 On Tue, Sep 5, 2017 at 10:47 AM, Benedikt Ritterwrote: > Hi, > > since we’re getting more and more requests about the deprecation of > RandomStringUtils, I’m thinking about releasing the current state of the > master branch as 3.6.1. I may have time to push an RC sometime this week. > So if you have some fixes you want to include, please do so now. > > Regards, > Benedikt > - > 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 Commons Jelly 1.0.1 based on RC3.
On Sat, Sep 2, 2017 at 11:35 PM, Amey Jadiye <ameyjad...@gmail.com> wrote: > That would be really nice, also why trunk and tag don't looks similar ? > > Is this something we added recently and not present in trunk ? I saw BUILDING.md only in tag, whatever written in .md is ok thought its good to simply have Dockerfile in same tag and give simple one liner command in BUILDING.md https://svn.apache.org/repos/asf/commons/proper/jelly/tags/commons-jelly-1.0.1-RC3/ https://svn.apache.org/repos/asf/commons/proper/jelly/trunk/ https://github.com/apache/commons-jelly Regards, Amey > > On Sat, Sep 2, 2017 at 11:26 PM, Rob Tompkins <chtom...@gmail.com> wrote: > >> >> >> > On Sep 2, 2017, at 1:42 PM, Amey Jadiye <ameyjad...@gmail.com> wrote: >> > >> > I'm sorry, I did not find the Dockerfile in repository, where can i get >> > install.sh ? what are you trying here ? >> > >> >> Since you and Gary couldn't immediately figure it out? You think I should >> simply automate all of that with one command going for an RC4. I'm not >> opposed if things aren't clear enough. >> >> Cheers, >> -Rob >> >> > Regards, >> > Amey >> > >> >> On Sat, Sep 2, 2017 at 9:10 PM, Gary Gregory <garydgreg...@gmail.com> >> wrote: >> >> >> >> Having a bit of trouble with getting Docker up and running: >> >> >> >> C:\temp\rc\test>docker build -t commons-jelly-build-env . >> >> Sending build context to Docker daemon 48.57MB >> >> Step 1/9 : FROM library/ubuntu:12.04 >> >> ---> 5b117edd0b76 >> >> Step 2/9 : RUN apt-get -qq update && apt-get install -y curl wget pgp >> >> subversion >> >> ---> Using cache >> >> ---> 09222f9bff4e >> >> Step 3/9 : RUN mkdir -p /usr/java >> >> ---> Using cache >> >> ---> 452385c30506 >> >> Step 4/9 : ADD jdk-1_5_0_22-linux-amd64.bin /tmp >> >> ---> Using cache >> >> ---> 7900a2972247 >> >> Step 5/9 : ADD answer.txt /tmp >> >> ---> Using cache >> >> ---> 374f6faca534 >> >> Step 6/9 : ADD install.sh /tmp >> >> ---> Using cache >> >> ---> daa85b4e7f54 >> >> Step 7/9 : RUN chmod +x /tmp/install.sh && sh /tmp/install.sh >> >> ---> Running in 7e419092032b >> >> : not foundl.sh: 1: /tmp/install.sh: >> >> % Total% Received % Xferd Average Speed TimeTime Time >> >> Current >> >> Dload Upload Total SpentLeft >> >> Speed >> >> 100 7553k 100 7553k0 0 611k 0 0:00:12 0:00:12 >> --:--:-- >> >> 883k >> >> tar: 1\r: Invalid number of elements >> >> Try `tar --help' or `tar --usage' for more information. >> >> : not foundl.sh: 5: /tmp/install.sh: >> >> : not foundl.sh: 7: /tmp/install.sh: >> >> : not foundl.sh: 23: /tmp/install.sh: >> >> % Total% Received % Xferd Average Speed TimeTime Time >> >> Current >> >> Dload Upload Total SpentLeft >> >> Speed >> >> 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- >> >> 0Warning: Failed to create the file >> >> : No such root/.maven/repository/servletapi/jars/servletapi-2.3.jar >> >> Warning: file or directory >> >> 20 77977 20 161550 0 27715 0 0:00:02 --:--:-- 0:00:02 >> >> 38011 >> >> curl: (23) Failed writing body (0 != 16155) >> >> % Total% Received % Xferd Average Speed TimeTime Time >> >> Current >> >> Dload Upload Total SpentLeft >> >> Speed >> >> 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- >> >> 0Warning: Failed to create the file >> >> : No ng: /root/.maven/repository/commons-cli/jars/commons-cli-1.0.jar >> >> Warning: such file or directory >> >> 53 30117 53 161550 0 40024 0 --:--:-- --:--:-- --:--:-- >> >> 47236 >> >> curl: (23) Failed writing body (0 != 16155) >> >> % Total% Received % Xferd Average Speed TimeTime Time >> >> Current >> >> Dload Upload Total SpentLeft >> >> Speed >> >> 0 00 00 0 0 0 --:--:-- --:--:-- --:--
Re: [VOTE] Release Commons Jelly 1.0.1 based on RC3.
That would be really nice, also why trunk and tag don't looks similar ? On Sat, Sep 2, 2017 at 11:26 PM, Rob Tompkins <chtom...@gmail.com> wrote: > > > > On Sep 2, 2017, at 1:42 PM, Amey Jadiye <ameyjad...@gmail.com> wrote: > > > > I'm sorry, I did not find the Dockerfile in repository, where can i get > > install.sh ? what are you trying here ? > > > > Since you and Gary couldn't immediately figure it out? You think I should > simply automate all of that with one command going for an RC4. I'm not > opposed if things aren't clear enough. > > Cheers, > -Rob > > > Regards, > > Amey > > > >> On Sat, Sep 2, 2017 at 9:10 PM, Gary Gregory <garydgreg...@gmail.com> > wrote: > >> > >> Having a bit of trouble with getting Docker up and running: > >> > >> C:\temp\rc\test>docker build -t commons-jelly-build-env . > >> Sending build context to Docker daemon 48.57MB > >> Step 1/9 : FROM library/ubuntu:12.04 > >> ---> 5b117edd0b76 > >> Step 2/9 : RUN apt-get -qq update && apt-get install -y curl wget pgp > >> subversion > >> ---> Using cache > >> ---> 09222f9bff4e > >> Step 3/9 : RUN mkdir -p /usr/java > >> ---> Using cache > >> ---> 452385c30506 > >> Step 4/9 : ADD jdk-1_5_0_22-linux-amd64.bin /tmp > >> ---> Using cache > >> ---> 7900a2972247 > >> Step 5/9 : ADD answer.txt /tmp > >> ---> Using cache > >> ---> 374f6faca534 > >> Step 6/9 : ADD install.sh /tmp > >> ---> Using cache > >> ---> daa85b4e7f54 > >> Step 7/9 : RUN chmod +x /tmp/install.sh && sh /tmp/install.sh > >> ---> Running in 7e419092032b > >> : not foundl.sh: 1: /tmp/install.sh: > >> % Total% Received % Xferd Average Speed TimeTime Time > >> Current > >> Dload Upload Total SpentLeft > >> Speed > >> 100 7553k 100 7553k0 0 611k 0 0:00:12 0:00:12 --:--:-- > >> 883k > >> tar: 1\r: Invalid number of elements > >> Try `tar --help' or `tar --usage' for more information. > >> : not foundl.sh: 5: /tmp/install.sh: > >> : not foundl.sh: 7: /tmp/install.sh: > >> : not foundl.sh: 23: /tmp/install.sh: > >> % Total% Received % Xferd Average Speed TimeTime Time > >> Current > >> Dload Upload Total SpentLeft > >> Speed > >> 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- > >> 0Warning: Failed to create the file > >> : No such root/.maven/repository/servletapi/jars/servletapi-2.3.jar > >> Warning: file or directory > >> 20 77977 20 161550 0 27715 0 0:00:02 --:--:-- 0:00:02 > >> 38011 > >> curl: (23) Failed writing body (0 != 16155) > >> % Total% Received % Xferd Average Speed TimeTime Time > >> Current > >> Dload Upload Total SpentLeft > >> Speed > >> 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- > >> 0Warning: Failed to create the file > >> : No ng: /root/.maven/repository/commons-cli/jars/commons-cli-1.0.jar > >> Warning: such file or directory > >> 53 30117 53 161550 0 40024 0 --:--:-- --:--:-- --:--:-- > >> 47236 > >> curl: (23) Failed writing body (0 != 16155) > >> % Total% Received % Xferd Average Speed TimeTime Time > >> Current > >> Dload Upload Total SpentLeft > >> Speed > >> 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- > >> 0Warning: Failed to create the file > >> : No ng: /root/.maven/repository/commons-lang/jars/commons-lang-2.0.jar > >> Warning: such file or directory > >> 9 165k9 161530 0 34086 0 0:00:04 --:--:-- 0:00:04 > >> 39785 > >> curl: (23) Failed writing body (0 != 16153) > >> % Total% Received % Xferd Average Speed TimeTime Time > >> Current > >> Dload Upload Total SpentLeft > >> Speed > >> 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- > >> 0Warning: Failed to create the file > >> Warning: > >> /root/.maven/repository/commons-discovery/jars/commons-discovery-20030 > >> : No such file or directory > >> 22 72176 22 16
Re: [VOTE] Release Commons Jelly 1.0.1 based on RC3.
I'm sorry, I did not find the Dockerfile in repository, where can i get install.sh ? what are you trying here ? Regards, Amey On Sat, Sep 2, 2017 at 9:10 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > Having a bit of trouble with getting Docker up and running: > > C:\temp\rc\test>docker build -t commons-jelly-build-env . > Sending build context to Docker daemon 48.57MB > Step 1/9 : FROM library/ubuntu:12.04 > ---> 5b117edd0b76 > Step 2/9 : RUN apt-get -qq update && apt-get install -y curl wget pgp > subversion > ---> Using cache > ---> 09222f9bff4e > Step 3/9 : RUN mkdir -p /usr/java > ---> Using cache > ---> 452385c30506 > Step 4/9 : ADD jdk-1_5_0_22-linux-amd64.bin /tmp > ---> Using cache > ---> 7900a2972247 > Step 5/9 : ADD answer.txt /tmp > ---> Using cache > ---> 374f6faca534 > Step 6/9 : ADD install.sh /tmp > ---> Using cache > ---> daa85b4e7f54 > Step 7/9 : RUN chmod +x /tmp/install.sh && sh /tmp/install.sh > ---> Running in 7e419092032b > : not foundl.sh: 1: /tmp/install.sh: > % Total% Received % Xferd Average Speed TimeTime Time > Current > Dload Upload Total SpentLeft > Speed > 100 7553k 100 7553k0 0 611k 0 0:00:12 0:00:12 --:--:-- > 883k > tar: 1\r: Invalid number of elements > Try `tar --help' or `tar --usage' for more information. > : not foundl.sh: 5: /tmp/install.sh: > : not foundl.sh: 7: /tmp/install.sh: > : not foundl.sh: 23: /tmp/install.sh: > % Total% Received % Xferd Average Speed TimeTime Time > Current > Dload Upload Total SpentLeft > Speed > 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- > 0Warning: Failed to create the file > : No such root/.maven/repository/servletapi/jars/servletapi-2.3.jar > Warning: file or directory > 20 77977 20 161550 0 27715 0 0:00:02 --:--:-- 0:00:02 > 38011 > curl: (23) Failed writing body (0 != 16155) > % Total% Received % Xferd Average Speed TimeTime Time > Current > Dload Upload Total SpentLeft > Speed > 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- > 0Warning: Failed to create the file > : No ng: /root/.maven/repository/commons-cli/jars/commons-cli-1.0.jar > Warning: such file or directory > 53 30117 53 161550 0 40024 0 --:--:-- --:--:-- --:--:-- > 47236 > curl: (23) Failed writing body (0 != 16155) > % Total% Received % Xferd Average Speed TimeTime Time > Current > Dload Upload Total SpentLeft > Speed > 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- > 0Warning: Failed to create the file > : No ng: /root/.maven/repository/commons-lang/jars/commons-lang-2.0.jar > Warning: such file or directory > 9 165k9 161530 0 34086 0 0:00:04 --:--:-- 0:00:04 > 39785 > curl: (23) Failed writing body (0 != 16153) > % Total% Received % Xferd Average Speed TimeTime Time > Current > Dload Upload Total SpentLeft > Speed > 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- > 0Warning: Failed to create the file > Warning: > /root/.maven/repository/commons-discovery/jars/commons-discovery-20030 > : No such file or directory > 22 72176 22 161370 0 34268 0 0:00:02 --:--:-- 0:00:02 > 39551 > curl: (23) Failed writing body (0 != 16137) > % Total% Received % Xferd Average Speed TimeTime Time > Current > Dload Upload Total SpentLeft > Speed > 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- > 0Warning: Failed to create the file > : No ng: /root/.maven/repository/forehead/jars/forehead-1.0-beta-5.jar > Warning: such file or directory > 100 12847 100 128470 0 31595 0 --:--:-- --:--:-- --:--:-- > 38008 > curl: (23) Failed writing body (0 != 12847) > % Total% Received % Xferd Average Speed TimeTime Time > Current > Dload Upload Total SpentLeft > Speed > 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- > 0Warning: Failed to create the file > : No such file or ven/repository/jstl/jars/jstl-1.0.6.jar > Warning: directory > 77 20812 77 161600 0 36816 0 --:--:-- --:--:-- --:--:-- > 43093 > curl: (23) Failed writing body (0 != 16160) > % Total% Received % Xferd Average Speed TimeTime
Re: [VOTE] Release Apache Commons CSV 1.5 based on RC1
Checked RC1, and here is my +1 (non-binding). 1. Build and Tests looks good. 2. Clirr looks good. 3. Rat is good. 4. Findbug is failing with Error SF_SWITCH_FALLTHROUGH but no issues since mentioned in comment *break intentionally excluded* 5. Checkstyle looks good. 6. Hashes looks good. 7. Site looks good. Checked on :- Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T22:11:47+05:30) Maven home: /opt/apache/maven Java version: 1.8.0_111, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-8-oracle/jre Default locale: en_IN, platform encoding: UTF-8 OS name: "linux", version: "4.4.0-31-generic", arch: "amd64", family: "unix" Regards, Amey On Sun, Aug 27, 2017 at 3:40 PM, Bruno P. Kinoshita < brunodepau...@yahoo.com.br.invalid> wrote: > Hello all, > > This is a [VOTE] for releasing Apache Commons CSV 1.5 (from RC1). > > Tag name: > csv-1.5-RC1 (signature can be checked from git using 'git tag -v') > Tag URL: > https://git-wip-us.apache.org/repos/asf?p=commons-csv.git;a=commit;h= > f76a1357057cd3caaf9b0904d9cc57ce384658a3 > Commit ID the tag points at: > f76a1357057cd3caaf9b0904d9cc57ce384658a3 > > Site: > http://people.apache.org/~kinow/commons-csv-1.5-RC1/ > Distribution files (committed at revision 21311): > https://dist.apache.org/repos/dist/dev/commons/csv/ > > Distribution files hashes (SHA1): > commons-csv-1.5-bin.tar.gz > (SHA1: 4c2a4cde27c556f808cd354807579a208fcf) > commons-csv-1.5-bin.zip > (SHA1: fea9c15a06e1f660b2bba30a5fba44a76492c02e) > commons-csv-1.5-src.tar.gz > (SHA1: e2c83f040fdfdb868184c019624d20b79113e004) > commons-csv-1.5-src.zip > (SHA1: 22f009e0e7be51c3c61fa667c02ac1822276c7b8) > > These are the Maven artifacts and their hashes: > commons-csv-1.5-javadoc.jar > (SHA1: 8008b611f677b9ba06988e8102887fa4caed93b5) > commons-csv-1.5-sources.jar > (SHA1: b76c277916ffef14d63279b896b6a82252ddeb79) > commons-csv-1.5-test-sources.jar > (SHA1: f7771a23ac6ec7d5183c65146135e51f6bf2c8fb) > commons-csv-1.5-tests.jar > (SHA1: 1209d9e86a83ac06d139ea02c4331a1426051ee7) > commons-csv-1.5.jar > (SHA1: e10f140af5b82167640f254fa9d88e35ad74329c) > commons-csv-1.5.pom > (SHA1: cffa8d9814f6d711a3cb57865e65927b1f54dcb0) > > KEYS file to check signatures: > http://www.apache.org/dist/commons/KEYS > > Maven artifacts: > https://repository.apache.org/content/repositories/orgapachecommons-1257 > Please select one of the following options[1]: > > [ ] +1 Release it. > [ ] +0 Go ahead; I don't care. > [ ] -0 There are a few minor glitches: ... > [ ] -1 No, do not release it because ... > > This vote will be open at least 72 hours, i.e. until 2017-08-30T10:00:00Z > (this is UTC time). > > > Cheers, > > -Bruno > > [1] http://apache.org/foundation/voting.html > ps: I submitted this vote e-mail before at 06:00:00 UTC, but looks like > the e-mail did not go through, so waited some hours before sending it again > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Fwd: RandomStringUtils and RandomStringGenerator
I'm ok with quick fix to un-deprecate it in lang but 2nd option seems good for long term. Its on my to-do list , I will see if I can do something on that. Regards, Amey On Sun, Aug 27, 2017, 3:18 PM Pascal Schumacher <pascalschumac...@gmx.net> wrote: > The plan was either to un-deprecate the method in lang or add > RandomStringUtils - with the current interface, but using > RandomStringGenerator - to text. > > The first option is easily archived, while the second requires > significant effort. Also long implements the second option we stick to > the first option. > > Cheers, > Pascal > > Am 23.08.2017 um 21:39 schrieb Amey Jadiye: > > I think we should keep that deprecated in lang and go with plan discussed > > in below mail trail. > > > > http://markmail.org/message/azxw4nai7fs2laas > > > > Regards, > > Amey > > > > -- Forwarded message -- > > From: Gilles <gil...@harfang.homelinux.org> > > Date: Wed, Aug 23, 2017 at 7:40 PM > > Subject: Re: RandomStringUtils and RandomStringGenerator > > To: u...@commons.apache.org > > > > > > Hi. > > > > On Tue, 22 Aug 2017 14:49:38 -0700, Russell Bolles wrote: > > > >> Good afternoon, > >> > >> I recently happened to pick up commons-lang:3.6 and noticed that > >> RandomStringUtils was deprecated in favor of > >> commons-text:RandomStringGenerator. > >> > >> I work on a moderately sized Java service and a quick find usages in > >> IntelliJ shows that I have 452 usages of RandomStringUtils, mostly in my > >> tests. > >> > >> Was there any discussion of moving the RandomStringUtils class to > >> commons-text and preserving the API as it stands now? What benefits do > we > >> get when throwing out the RandomStringUtils class altogether in favor a > of > >> a fluent builder (i.e. RandomStringGenerator). > >> > >> I can't emphasize enough how useful it is to be able to create a random > >> string via a static method especially when writing unit tests. > >> > > Good news for you :-) > >https://issues.apache.org/jira/browse/LANG-1346 > > > > Regards, > > Gilles > > > > > >> Thank you for your time. > >> > > > > - > > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > > For additional commands, e-mail: user-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 > >
Fwd: RandomStringUtils and RandomStringGenerator
I think we should keep that deprecated in lang and go with plan discussed in below mail trail. http://markmail.org/message/azxw4nai7fs2laas Regards, Amey -- Forwarded message -- From: Gilles <gil...@harfang.homelinux.org> Date: Wed, Aug 23, 2017 at 7:40 PM Subject: Re: RandomStringUtils and RandomStringGenerator To: u...@commons.apache.org Hi. On Tue, 22 Aug 2017 14:49:38 -0700, Russell Bolles wrote: > Good afternoon, > > I recently happened to pick up commons-lang:3.6 and noticed that > RandomStringUtils was deprecated in favor of > commons-text:RandomStringGenerator. > > I work on a moderately sized Java service and a quick find usages in > IntelliJ shows that I have 452 usages of RandomStringUtils, mostly in my > tests. > > Was there any discussion of moving the RandomStringUtils class to > commons-text and preserving the API as it stands now? What benefits do we > get when throwing out the RandomStringUtils class altogether in favor a of > a fluent builder (i.e. RandomStringGenerator). > > I can't emphasize enough how useful it is to be able to create a random > string via a static method especially when writing unit tests. > Good news for you :-) https://issues.apache.org/jira/browse/LANG-1346 Regards, Gilles > Thank you for your time. > - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-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] Move Apache Commons Discovery to dormant?
+1 On Sun, Aug 20, 2017 at 3:44 PM, Pascal Schumacherwrote: > Hi all, > > as discussed, I'd like to propose to move Apache Commons Discovery to > dormant. > > Reasons: > - Last release was version 0.5 in 2011. > - The last bugfix and feature commits are from 2011. > - Not a single jira issue has been created since 2011. > > So please cast your votes: > This vote will close no sooner that 72 hours from now, > i.e. after 13:00CET 23 August 2017 > > [ ] +1 Move Commons Discovery to dormant > [ ] +/-0 I'm undecided on this concern > [ ] -1 No, do NOT move Commons Discovery to dormant (because) > > Thanks! > Pascal > > > - > 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] Move Apache Commons Launcher to dormant?
+1 On Sun, Aug 20, 2017 at 3:41 PM, Pascal Schumacherwrote: > Hi all, > > as discussed, I'd like to propose to move Apache Commons Launcher to > dormant. > > Reasons: > - The last release is from 2007. > - No bugfix or feature addition commits since 2007. > > So please cast your votes: > This vote will close no sooner that 72 hours from now, > i.e. after 13:00CET 23 August 2017 > > [ ] +1 Move Commons Launcher to dormant > [ ] +/-0 I'm undecided on this concern > [ ] -1 No, do NOT move Commons Launcher to dormant (because) > > Thanks! > Pascal > > > - > 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][Math] New component: "Commons Geometry"?
I'm +1 to this change, I would be more than happy to lend my hands to help on this front. pardon me for being quite because some heavy work on my day job. I don't want to fork this thread to different discussion but I have one simple doubt that rather creating whole new component why don't we just create maven modules within CM ? I understand that release becomes easy with different component and some more other advantages but same can be done within single project. this is obvious question and which you guys might have discussed before but I didn't found it in past mail archives, though I saw a fork of CM made last year and "that" code base is doing exactly what my doubt is. i.e sub-component as maven module. Regards, Amey On Tue, Aug 15, 2017 at 7:56 PM, Gilles <gil...@harfang.homelinux.org> wrote: > Hello. > > [Time for a new episode in our "Ripping CM" series.] > > How about creating "Commons Geometry"? > > The rationale is comprised of the usual suspects: > * Smaller and more focused component, hence: >- Consistent development and maintenance. >- Consistent release schedule, not encumbered by > changes (and endless discussions) in _totally_ > unrelated code. >- Potential for attracting contributors not > interested in maintaining the (growing) backlog > of CM. > * Self-contained: 96.3% of the "o.a.c.math4.geometry" >package have no dependency except: >- 4 classes now in "Commons Numbers". >- 2 methods and 1 constant in "MathUtils". >- CM exceptions. [Creating alternatives for those > will probably be the most time-consuming part of > the porting work.] > > Moreover, none of the code in the "o.a.c.math4.geometry" > package is used by another package of CM. > > A new component would give the "geometry" codes a much > better chance of being (confidently[1]) released, since > CM is "stuck" for the foreseeable future.[2] > > WDYT? > > Gilles > > [1] There seems to be only one issue reported in JIRA > that pertains to "geometry". > [2] 54 issues yet to be fixed before the 4.0 release; > which, at the current rate, would lead to after 2025 > (a very rough guess, I admit). > > > - > 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/travis-ci] Regarding potential Travis-CI solutions
Closed PR. On Mon, Aug 7, 2017 at 2:12 AM, Amey Jadiye <ameyjad...@gmail.com> wrote: > looking at inclination of community I will be closing the PR without > expecting merge after a week by 14th August 2017 unless someone see it's > useful. > > Reference will be there in closed PR list on github so if someone need it > in future it will be there. > > Regards, > Amey > > > On Fri, Aug 4, 2017, 3:02 AM Rob Tompkins <chtom...@gmail.com> wrote: > >> Hello all, >> >> We have an open pull request from Amey (https://github.com/apache/ >> commons-text/pull/61 <https://github.com/apache/commons-text/pull/61>) >> proposing a fairly complicated but quite nice travis-ci build solution >> (taken from the jacoco project) that accommodates building on JDK7, JDK8, >> JDK8-ea, EclipseJava, JDK9-ea, as well as IBMJava-8. To accommodate >> building on all of these different versions of Java, we do however need to >> make the travis-ci build a good deal more complex. >> >> As the two reviewers on the pull request, Pascal and myself, have mildly >> differing opinions on the complexity-value trade off here, with Pascal’s >> opinion being: "…[T]his is overkill. I don't think commons-text needs to be >> tested against the eclipse java compiler and early access versions of java >> 8 and 9. The script looks difficult to debug and maintain.” And my >> perspective is that this could be a test piece for using this elsewhere in >> commons. >> >> To me, the argument for simplicity is always quite compelling, to the >> point that I’m mostly willing to let go of using the jacoco travis-ci >> pattern. But I figured I would, before making any decisions, see what the >> community thinks generally about this possible travis-ci build script. >> >> Cheers, >> -Rob > > -- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Empty repositories for some retired components on github
+1, If something is/will not in use better delete them. Cheers, Amey On Sun, Aug 13, 2017, 11:54 PM Pascal Schumacher <pascalschumac...@gmx.net> wrote: > Hello everybody, > > just a small detail. > > For some retired components there are still github mirrors (with an > empty repository): > > https://github.com/apache/commons-primitives > > https://github.com/apache/commons-betwixt > > https://github.com/apache/commons-attributes > > Should I create an infra ticket in order to let these mirrors be > deactivated? > > Cheers, > > Pascal > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [All] Jenkins: where are the projects?
I do remember Infra team warned in end of July '17 to remove Commons from top-level to A-D or C tab else they were about to remove it on 1st August '17 ... And they did it . But no worries we already had it in A-D tab. https://builds.apache.org/view/A-D/view/Commons/ Regards, Amey On Thu, Aug 10, 2017, 5:49 AM Gary Gregory <garydgreg...@gmail.com> wrote: > I thought we already had a new view, I guess not :-( > > Gary > > On Wed, Aug 9, 2017 at 5:17 PM, Gilles <gil...@harfang.homelinux.org> > wrote: > > > Hi. > > > > The top view does not show "Commons" anymore. > > [I do recall some notice about a change on Jenkins. > > But, no, I don't know whether every developer had to > > do something and, if so, what and how...] > > > > Thanks, > > Gilles > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > >
Re: Ready for JDK 9 ?
Hi Jorg, Yes, I think rather just checking latest released source we should check the HEAD of components to ensure we will not break next planned release with java 9, at least we can fix if there is some issue from java9 RC it self, that will ensure future stability. Looking at commons-text latest build via Travis its still using EA, Java HotSpot(TM) 64-Bit Server VM (build 9+175, mixed mode)., RC is build 9+181. I have raised requested Travis-ci to update it [1] , lets see. [1] https://github.com/travis-ci/travis-ci/issues/8233 Regards, Amey On Wed, Aug 9, 2017 at 1:33 PM, Jörg Schaible < joerg.schai...@bpm-inspire.com> wrote: > Hi Amey, > > Amey Jadiye wrote: > > > Hmm, isn't that easy with just Travis ? We just have to add java9 > > option(not sure it have RC) and trigger build it will automatically check > > build and tests. IIRC for few components we are having java9 Travis env > > already set. > > That would only ensure that the head revision runs with the Java 9 version, > that is supplied by Travis ... is that already the RC? > > Cheers, > Jörg > > > - > 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: Ready for JDK 9 ?
Hmm, isn't that easy with just Travis ? We just have to add java9 option(not sure it have RC) and trigger build it will automatically check build and tests. IIRC for few components we are having java9 Travis env already set. Regards, Amey On Tue, Aug 8, 2017, 8:38 PM Jörg Schaible <joerg.schai...@bpm-inspire.com> wrote: > Hi, > > Gilles wrote: > > > Hi. > > > > On Tue, 8 Aug 2017 11:09:01 +0100, Rory O'Donnell wrote: > >> Hi Benedikt, > >> > >> Thank you very much for all your testing of JDK 9 during its > >> development! Such contributions have significantly helped shape and > >> improve JDK 9. > >> > >> Now that we have reached the JDK 9 Final Release Candidate phase [1] > >> , I would like to ask if your project can be considered to be 'ready > >> for JDK 9', > > > > Is there some simple thing to do in order to be able to answer > > that question? > > IMHO no. Definitelly not in general for all components. Practically we > would > have to checkout the latest releases from source (or use the source > tarballs) and run at least the unit tests with this Java 9 RC. > > Cheers, > Jörg > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [all/travis-ci] Regarding potential Travis-CI solutions
looking at inclination of community I will be closing the PR without expecting merge after a week by 14th August 2017 unless someone see it's useful. Reference will be there in closed PR list on github so if someone need it in future it will be there. Regards, Amey On Fri, Aug 4, 2017, 3:02 AM Rob Tompkins <chtom...@gmail.com> wrote: > Hello all, > > We have an open pull request from Amey ( > https://github.com/apache/commons-text/pull/61 < > https://github.com/apache/commons-text/pull/61>) proposing a fairly > complicated but quite nice travis-ci build solution (taken from the jacoco > project) that accommodates building on JDK7, JDK8, JDK8-ea, EclipseJava, > JDK9-ea, as well as IBMJava-8. To accommodate building on all of these > different versions of Java, we do however need to make the travis-ci build > a good deal more complex. > > As the two reviewers on the pull request, Pascal and myself, have mildly > differing opinions on the complexity-value trade off here, with Pascal’s > opinion being: "…[T]his is overkill. I don't think commons-text needs to be > tested against the eclipse java compiler and early access versions of java > 8 and 9. The script looks difficult to debug and maintain.” And my > perspective is that this could be a test piece for using this elsewhere in > commons. > > To me, the argument for simplicity is always quite compelling, to the > point that I’m mostly willing to let go of using the jacoco travis-ci > pattern. But I figured I would, before making any decisions, see what the > community thinks generally about this possible travis-ci build script. > > Cheers, > -Rob
Re: [VOTE] Release Apache Commons JCS 2.2 based on RC1
+1 (non-binding) On Wed, Aug 2, 2017 at 7:02 PM, Thomas Vandahlwrote: > I would like to release the [jcs] component to resolve some overdue bugs > > Apache Commons JCS 2.2 RC1 is available for review at: > https://dist.apache.org/repos/dist/dev/commons/jcs/ (r20728). > > Maven artifacts are at: > https://repository.apache.org/content/repositories/orgapachecommons-1256 > . > > The Subversion tag is: > > https://svn.apache.org/repos/asf/commons/proper/jcs/tags/commons-jcs-2.2 > (r1803806). > > The release notes are at: > > https://svn.apache.org/repos/asf/commons/proper/jcs/tags/ > commons-jcs-2.2/RELEASE-NOTES.txt > (r1803806). > > The staged site is available as a tarball at > > https://dist.apache.org/repos/dist/dev/commons/jcs/commons- > jcs-site-2.2.tar.gz > (r20723). > > Please review the release candidate and vote. > > [ ] +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 > > -- - 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 2.2 based on RC1
Ah, got it. Thanks -Amey On Sun, Aug 6, 2017, 12:57 AM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > 2017-08-05 19:41 GMT+02:00 Amey Jadiye <ameyjad...@gmail.com>: > > > Correct me if I'm wrong, but I see we have individual jars released for > > each modules. > > > > commons-jcs-jcache > > commons-jcs-core > > commons-jcs-jcache-tck > > .. > > .. > > > > > > and I see other than jcs few other projects have dependancy on jcache > [1], > > would that be and issue ? and this is not major version release. > > > > https://mvnrepository.com/artifact/org.apache.commons/ > > commons-jcs-jcache/2.1/usages > > > All of them rely on the JCache API and use JCS as an implementation so we > can break as much we want in our modules. > > > > > > > > Regards, > > Amey > > > > > > On Sat, Aug 5, 2017 at 9:37 PM, Romain Manni-Bucau < > rmannibu...@gmail.com> > > wrote: > > > > > Hmm, clirr shouldn't be applied to jcache since the compat guarantee is > > > done by jcache itself, not jcs where the module is just internals. > > > > > > > > > Romain Manni-Bucau > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > > <https://blog-rmannibucau.rhcloud.com> | Old Blog > > > <http://rmannibucau.wordpress.com> | Github <https://github.com/ > > > rmannibucau> | > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory > > > <https://javaeefactory-rmannibucau.rhcloud.com> > > > > > > 2017-08-05 17:51 GMT+02:00 Amey Jadiye <ameyjad...@gmail.com>: > > > > > > > Even for me build and tests working fine. > > > > > > > > [INFO] Reactor Summary: > > > > [INFO] > > > > [INFO] Apache Commons JCS . SUCCESS [ > > > > 10.196 s] > > > > [INFO] Apache Commons JCS :: Core . SUCCESS > > > [04:49 > > > > min] > > > > [INFO] Apache Commons JCS :: JCache ... SUCCESS [ > > > > 8.909 s] > > > > [INFO] Apache Commons JCS :: JCache TCK ... SUCCESS [ > > > > 4.089 s] > > > > [INFO] Apache Commons JCS :: JCache Extras SUCCESS [ > > > > 7.295 s] > > > > [INFO] Apache Commons JCS :: JCache OpenJPA ... SUCCESS [ > > > > 11.501 s] > > > > [INFO] Apache Commons JCS :: Distribution . SUCCESS [ > > > > 0.875 s] > > > > [INFO] > > > > > > > > > > [INFO] BUILD SUCCESS > > > > [INFO] > > > > > > > > > > [INFO] Total time: 05:33 min > > > > [INFO] Finished at: 2017-08-05T21:15:08+05:30 > > > > [INFO] Final Memory: 60M/895M > > > > [INFO] > > > > > > > > > > > > > > > > > > However Clirr is not good and findbug is also not good. > > > > > > > > [ERROR] 7002: org.apache.commons.jcs.jcache. > > proxy.ClassLoaderAwareCache: > > > > Method 'public boolean containsKey(java.io.Serializable)' has been > > > removed > > > > [ERROR] 7002: org.apache.commons.jcs.jcache. > > proxy.ClassLoaderAwareCache: > > > > Method 'public java.io.Serializable get(java.io.Serializable)' has > been > > > > removed > > > > [ERROR] 7002: org.apache.commons.jcs.jcache. > > proxy.ClassLoaderAwareCache: > > > > Method 'public java.io.Serializable getAndPut(java.io.Serializable, > > > > java.io.Serializable)' has been removed > > > > [ERROR] 7002: org.apache.commons.jcs.jcache. > > proxy.ClassLoaderAwareCache: > > > > Method 'public java.io.Serializable getAndRemove(java.io. > > Serializable)' > > > > has > > > > been removed > > > > [ERROR] 7002: org.apache.commons.jcs.jcache. > > proxy.ClassLoaderAwareCache: > > > > Method 'public java.io.Serializable getAndReplace(java.io. > > Serializable, > > > > java.io.Serializable)' has been removed > > > > [ERROR] 7002: org.apache.commons.jcs.jcache. > > proxy.ClassLoaderAwareCache: > > > > Method 'public java.lang.Object invoke(java.io
Re: [VOTE] Release Apache Commons JCS 2.2 based on RC1
Correct me if I'm wrong, but I see we have individual jars released for each modules. commons-jcs-jcache commons-jcs-core commons-jcs-jcache-tck .. .. and I see other than jcs few other projects have dependancy on jcache [1], would that be and issue ? and this is not major version release. https://mvnrepository.com/artifact/org.apache.commons/commons-jcs-jcache/2.1/usages Regards, Amey On Sat, Aug 5, 2017 at 9:37 PM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > Hmm, clirr shouldn't be applied to jcache since the compat guarantee is > done by jcache itself, not jcs where the module is just internals. > > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://blog-rmannibucau.rhcloud.com> | Old Blog > <http://rmannibucau.wordpress.com> | Github <https://github.com/ > rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory > <https://javaeefactory-rmannibucau.rhcloud.com> > > 2017-08-05 17:51 GMT+02:00 Amey Jadiye <ameyjad...@gmail.com>: > > > Even for me build and tests working fine. > > > > [INFO] Reactor Summary: > > [INFO] > > [INFO] Apache Commons JCS . SUCCESS [ > > 10.196 s] > > [INFO] Apache Commons JCS :: Core . SUCCESS > [04:49 > > min] > > [INFO] Apache Commons JCS :: JCache ... SUCCESS [ > > 8.909 s] > > [INFO] Apache Commons JCS :: JCache TCK ... SUCCESS [ > > 4.089 s] > > [INFO] Apache Commons JCS :: JCache Extras SUCCESS [ > > 7.295 s] > > [INFO] Apache Commons JCS :: JCache OpenJPA ... SUCCESS [ > > 11.501 s] > > [INFO] Apache Commons JCS :: Distribution . SUCCESS [ > > 0.875 s] > > [INFO] > > > > [INFO] BUILD SUCCESS > > [INFO] > > > > [INFO] Total time: 05:33 min > > [INFO] Finished at: 2017-08-05T21:15:08+05:30 > > [INFO] Final Memory: 60M/895M > > [INFO] > > > > > > > > However Clirr is not good and findbug is also not good. > > > > [ERROR] 7002: org.apache.commons.jcs.jcache.proxy.ClassLoaderAwareCache: > > Method 'public boolean containsKey(java.io.Serializable)' has been > removed > > [ERROR] 7002: org.apache.commons.jcs.jcache.proxy.ClassLoaderAwareCache: > > Method 'public java.io.Serializable get(java.io.Serializable)' has been > > removed > > [ERROR] 7002: org.apache.commons.jcs.jcache.proxy.ClassLoaderAwareCache: > > Method 'public java.io.Serializable getAndPut(java.io.Serializable, > > java.io.Serializable)' has been removed > > [ERROR] 7002: org.apache.commons.jcs.jcache.proxy.ClassLoaderAwareCache: > > Method 'public java.io.Serializable getAndRemove(java.io.Serializable)' > > has > > been removed > > [ERROR] 7002: org.apache.commons.jcs.jcache.proxy.ClassLoaderAwareCache: > > Method 'public java.io.Serializable getAndReplace(java.io.Serializable, > > java.io.Serializable)' has been removed > > [ERROR] 7002: org.apache.commons.jcs.jcache.proxy.ClassLoaderAwareCache: > > Method 'public java.lang.Object invoke(java.io.Serializable, > > javax.cache.processor.EntryProcessor, java.lang.Object[])' has been > > removed > > [ERROR] 7002: org.apache.commons.jcs.jcache.proxy.ClassLoaderAwareCache: > > Method 'public void put(java.io.Serializable, java.io.Serializable)' has > > been removed > > [ERROR] 7002: org.apache.commons.jcs.jcache.proxy.ClassLoaderAwareCache: > > Method 'public boolean putIfAbsent(java.io.Serializable, > > java.io.Serializable)' has been removed > > [ERROR] 7002: org.apache.commons.jcs.jcache.proxy.ClassLoaderAwareCache: > > Method 'public boolean remove(java.io.Serializable)' has been removed > > [ERROR] 7002: org.apache.commons.jcs.jcache.proxy.ClassLoaderAwareCache: > > Method 'public boolean remove(java.io.Serializable, > java.io.Serializable)' > > has been removed > > [ERROR] 7002: org.apache.commons.jcs.jcache.proxy.ClassLoaderAwareCache: > > Method 'public boolean replace(java.io.Serializable, > java.io.Serializable, > > java.io.Serializable)' has been removed > > [ERROR] 7002: org.apache.commons.jcs.jcache.proxy.ClassLoaderAwareCache: > > Method 'public boolean replace(java.io.Serializable, > java.io.Serializable)' > > has been removed > > [INFO] > > --
Re: [VOTE] Release Apache Commons JCS 2.2 based on RC1
Even for me build and tests working fine. [INFO] Reactor Summary: [INFO] [INFO] Apache Commons JCS . SUCCESS [ 10.196 s] [INFO] Apache Commons JCS :: Core . SUCCESS [04:49 min] [INFO] Apache Commons JCS :: JCache ... SUCCESS [ 8.909 s] [INFO] Apache Commons JCS :: JCache TCK ... SUCCESS [ 4.089 s] [INFO] Apache Commons JCS :: JCache Extras SUCCESS [ 7.295 s] [INFO] Apache Commons JCS :: JCache OpenJPA ... SUCCESS [ 11.501 s] [INFO] Apache Commons JCS :: Distribution . SUCCESS [ 0.875 s] [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 05:33 min [INFO] Finished at: 2017-08-05T21:15:08+05:30 [INFO] Final Memory: 60M/895M [INFO] However Clirr is not good and findbug is also not good. [ERROR] 7002: org.apache.commons.jcs.jcache.proxy.ClassLoaderAwareCache: Method 'public boolean containsKey(java.io.Serializable)' has been removed [ERROR] 7002: org.apache.commons.jcs.jcache.proxy.ClassLoaderAwareCache: Method 'public java.io.Serializable get(java.io.Serializable)' has been removed [ERROR] 7002: org.apache.commons.jcs.jcache.proxy.ClassLoaderAwareCache: Method 'public java.io.Serializable getAndPut(java.io.Serializable, java.io.Serializable)' has been removed [ERROR] 7002: org.apache.commons.jcs.jcache.proxy.ClassLoaderAwareCache: Method 'public java.io.Serializable getAndRemove(java.io.Serializable)' has been removed [ERROR] 7002: org.apache.commons.jcs.jcache.proxy.ClassLoaderAwareCache: Method 'public java.io.Serializable getAndReplace(java.io.Serializable, java.io.Serializable)' has been removed [ERROR] 7002: org.apache.commons.jcs.jcache.proxy.ClassLoaderAwareCache: Method 'public java.lang.Object invoke(java.io.Serializable, javax.cache.processor.EntryProcessor, java.lang.Object[])' has been removed [ERROR] 7002: org.apache.commons.jcs.jcache.proxy.ClassLoaderAwareCache: Method 'public void put(java.io.Serializable, java.io.Serializable)' has been removed [ERROR] 7002: org.apache.commons.jcs.jcache.proxy.ClassLoaderAwareCache: Method 'public boolean putIfAbsent(java.io.Serializable, java.io.Serializable)' has been removed [ERROR] 7002: org.apache.commons.jcs.jcache.proxy.ClassLoaderAwareCache: Method 'public boolean remove(java.io.Serializable)' has been removed [ERROR] 7002: org.apache.commons.jcs.jcache.proxy.ClassLoaderAwareCache: Method 'public boolean remove(java.io.Serializable, java.io.Serializable)' has been removed [ERROR] 7002: org.apache.commons.jcs.jcache.proxy.ClassLoaderAwareCache: Method 'public boolean replace(java.io.Serializable, java.io.Serializable, java.io.Serializable)' has been removed [ERROR] 7002: org.apache.commons.jcs.jcache.proxy.ClassLoaderAwareCache: Method 'public boolean replace(java.io.Serializable, java.io.Serializable)' has been removed [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache Commons JCS . SUCCESS [ 4.329 s] [INFO] Apache Commons JCS :: Core . SUCCESS [ 6.061 s] [INFO] Apache Commons JCS :: JCache ... FAILURE [ 3.886 s] [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: 16.543 s [INFO] Finished at: 2017-08-05T21:15:44+05:30 [INFO] Final Memory: 34M/272M [INFO] Regards, Amey - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org On Sat, Aug 5, 2017 at 7:57 PM, Oliver Heger <oliver.he...@oliver-heger.de> wrote: > > > Am 04.08.2017 um 17:32 schrieb Gary Gregory: > > Hi All: > > > > Can these failures be explained: > > > > Failed tests: > > RemoteCacheNoWaitUnitTest.testRemove:136 Wrong number updated. > > expected:<1> but was:<0> > > RemoteCacheNoWaitUnitTest.testUpdate:62 Wrong number updated. > > expected:<1> but was:<0> > > > > Tests run: 402, Failures: 2, Errors: 0, Skipped: 0 > > I do not see these failures. Running 'mvn clean inst
Re: [all/travis-ci] Regarding potential Travis-CI solutions
Hi, Yes we are giving up the simplicity of travis but I see some advantages over it, all of them are listed in my previous mail, let me try to put them again. 1. Travis provides very limited JDK at this point [1] and travis builds can become more flexible and we will have more control over the different flavours, versions and vendors of jdk we wants to use with travis build process. 2. Travis is very slow providing the different versions of jdk ATM. they don't have ibmjava8 not sure when ibmjava9 will be there ? 3. Complexity of file is limited to just one parent file, and its very generalised so we still have options to choose which jdk we want. 4. Script can contain specific version of stable JDK we want this gives more control to us for quickly updating next minor version rather waiting for Travis. 5. Other thing I'm proposing is to have this script as .travis.parent.sh and we can keep it somewhere centralised http location and wget it and execute from .travis.sh so core logic will have to maintain at single place, change will be only in respective .travis.yml. This script is modified kepping in mind that this will be usefull to all Commons components for their own specific needs and not onyl for text, Text is just test project. Even I don't want EA to be the part of script, I was just trying different options if anyone wants. Ex. for text I will have only below environment. env: - JDK=7 vendor=oracle - JDK=7 vendor=open - JDK=8 vendor=oracle - JDK=8 vendor=open ECJ=true - JDK=8 vendor=ibm - JDK=9 vendor=oracle - JDK=9 vendor=ibm [1]. https://docs.travis-ci.com/user/languages/java/ Regards, Amey On Fri, Aug 4, 2017 at 11:44 PM, Benedikt Ritter <brit...@apache.org> wrote: > I agree with Pascal. It's better to use Travis build in stuff. When IBM Jdk > really become available, that would be quite nice, because that tends to > cause failures. Regarding EA builds, I think it's good enough to test > releases against them. Since EA builds may have regressions, this could > lead to unstable builds. That's why I wouldn't make them part of my CI. > > Regards, > Benedikt > > Pascal Schumacher <pascalschumac...@gmx.net> schrieb am Fr. 4. Aug. 2017 > um > 18:20: > > > Hello everybody, > > > > let me add some detail to what I mean by hard to maintain. > > > > The scripts contains links to specific jdk versions: > > > > > > http://download.java.net/java/jdk9/archive/178/binaries/jdk- > 9+178_linux-x64_bin.tar.gz > > > > http://download.java.net/java/jdk9/archive/178/binaries/jdk- > 9+178_linux-x64_bin.tar.gz > > > > http://download.java.net/java/jdk8u152/archive/b05/binaries/ > jdk-8u152-ea-bin-b05-linux-x64-20_jun_2017.tar.gz > > > > http://public.dhe.ibm.com/ibmdl/export/pub/systems/ > cloud/runtimes/java/8.0.4.7/linux/x86_64/ibm-java-sdk-8.0- > 4.7-x86_64-archive.bin > > > > These have to be updated regularly, because what good is it to test > > against yesterdays EA versions? (They actually are already out of date > :(). > > > > Commons-text just uses a very stable and small parts of the jdk so I do > > not think it is very likely that something will break on a different > > variant. > > > > There is also a pull request to add the ibm jdk to travis: > > https://github.com/travis-ci/travis-cookbooks/pull/874 and a travis > > employee promised to take a look soon. So maybe travis will support the > > ibm jdk out of the box soon. > > > > Cheers, > > Pascal > > > > Am 03.08.2017 um 23:32 schrieb Rob Tompkins: > > > Hello all, > > > > > > We have an open pull request from Amey ( > > https://github.com/apache/commons-text/pull/61 < > > https://github.com/apache/commons-text/pull/61>) proposing a fairly > > complicated but quite nice travis-ci build solution (taken from the > jacoco > > project) that accommodates building on JDK7, JDK8, JDK8-ea, EclipseJava, > > JDK9-ea, as well as IBMJava-8. To accommodate building on all of these > > different versions of Java, we do however need to make the travis-ci > build > > a good deal more complex. > > > > > > As the two reviewers on the pull request, Pascal and myself, have > mildly > > differing opinions on the complexity-value trade off here, with Pascal’s > > opinion being: "…[T]his is overkill. I don't think commons-text needs to > be > > tested against the eclipse java compiler and early access versions of > java > > 8 and 9. The script looks difficult to debug and maintain.” And my > > perspective is that this could
Re: [RNG] Generating for nums
That convinced me +1. rng or lang both feels good to me. Regards, Amey On Fri, Aug 4, 2017 at 11:40 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > For example, I have a enum like: > > public enum CardinalDirection (NORTH,SOUTH,EAST,WEST) > > and I want to say > > traveler.travel(nextRandomDirection()); > > where > > public CardinalDirection nextRandomDirection() { >return rng.next(CardinalDirection.class); > } > > Gary > > On Fri, Aug 4, 2017 at 11:02 AM, Amey Jadiye <ameyjad...@gmail.com> wrote: > > > Hi, > > > > What's usecase for this BTW ? Might be unaware about requirement but this > > forced me to think why would someone need random enum ? > > > > Enums are generally "limited" immutable constants and people choose enum > > over the array of constants for good reason, however random provider > seems > > best suited for choosing value from any Data-Structure holding "lot" of > > values. > > > > I think it's little weird but I would be happy if someone explain > > advantages. :-) > > > > Regards, > > Amey > > > > On Fri, Aug 4, 2017, 11:17 PM Gary Gregory <garydgreg...@gmail.com> > wrote: > > > > > Hi All, > > > > > > Any thoughts on generation when you want to the domain to be an enum? > > > > > > SomeEnum e = UniformRandomProvider.next(SomeEnum); > > > > > > ? > > > > > > Is that too weird for this component? > > > > > > Gary > > > > > > -- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [RNG] Generating for nums
Hi, What's usecase for this BTW ? Might be unaware about requirement but this forced me to think why would someone need random enum ? Enums are generally "limited" immutable constants and people choose enum over the array of constants for good reason, however random provider seems best suited for choosing value from any Data-Structure holding "lot" of values. I think it's little weird but I would be happy if someone explain advantages. :-) Regards, Amey On Fri, Aug 4, 2017, 11:17 PM Gary Gregory <garydgreg...@gmail.com> wrote: > Hi All, > > Any thoughts on generation when you want to the domain to be an enum? > > SomeEnum e = UniformRandomProvider.next(SomeEnum); > > ? > > Is that too weird for this component? > > Gary >
Re: Help with task: Implement Ziggurat algorithm
Hello 仓央杰克 , If you are not in possition to submit this I'm taking this task up for completion. I will submit my PR in a week or so you may give your inputs on that. Regards, Amey On Jul 5, 2017 10:20 AM, "Amey Jadiye" <ameyjad...@gmail.com> wrote: code should go in commons rng btw. here is repo link and contribution guide lines https://github.com/apache/commons-rng Regards, Amey On Tue, Jul 4, 2017, 11:46 PM Amey Jadiye <ameyjad...@gmail.com> wrote: > Hello, > > your contribution will always be welcome, you can provide your code via > github pull request. > read contribution guidelines before submitting PR, > https://github.com/apache/commons-numbers > > Regards, > Amey > > On Mon, Jun 19, 2017 at 8:00 PM, 仓央杰克 <lqjack...@126.com> wrote: > >> I would like to help out with the task listed at >> https://helpwanted.apache.org/task.html?9d71a269 >> > > > > -- > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org >
Re: [all/travis-ci] Regarding using ibmjava on travis
Hello All, We need community opinion here as this change request can improve / affect many other components in near future. I have proposed the change in PR https://github.com/apache/commons-text/pull/61 so the travis builds can become more flexible and we will have more control over the different flavours, versions and vendors of jdk we wants to use via travis build process. I personally think that travis is very slow providing the different versions of jdk ATM ... PR contains two files one is generic .travis.sh which is generalised and .travis.yml which is commons-text specific. Some may feel script is complex [I don't think it is complex might be because I worked on it ;-)] but once it become mature it will be pretty stable and need no change, depending on components requirements each can decide which jdk/vendor/version they want in their .travis.yml For the sake of start and demo I have added wide verity of jdk in build like java7, java8, java9, earyl access, eclipse compiler option, oraclejdk, openjdk, ibm jdk etc and that can me made configurable easily so no much maintenance needed once we are done with it, I'm expecting improvements / suggestions from you guys to improve it more for the need of commons. Other thing I'm proposing is to have this script as .travis.parent.sh and we can keep it somewhere centralised http location and wget it and execute from .travis.sh so core logic will have to maintain at single place, change will be only in respective .travis.yml. what do you guys think ? Regards, Amey On Fri, Jul 28, 2017 at 6:02 PM, Amey Jadiye <ameyjad...@gmail.com> wrote: > Thanks, I'm taking Commons Text as my test guineapig for jacoco style > implementation , once confident in implementation we can move it to other > components. > > Regards, > Amey > > On Jul 28, 2017 5:39 PM, "Rob Tompkins" <chtom...@gmail.com> wrote: > >> >> > On Jul 27, 2017, at 4:10 PM, Amey Jadiye <ameyjad...@gmail.com> wrote: >> > >> > Hi Rob, >> > >> > If this is still pending I would like to pickup this task. If docker is >> not >> > much helpful OR we need to wait for it I think we should try what >> jacoco >> > did. what do you think ? >> >> Sure. That makes sense to me, especially since the Travis folks say that >> they’ve got on the backlog to install the IBM JDKs on their build >> environments. >> >> > >> > Is it mandatory to use official java images ?Else I am also thinking to >> > create my own ibmjdk8 image on top of given by IBM and have some tools >> and >> > scrips ready in that so on fail it should return -1. >> >> I contributed to the official maven docker image to add the ibm jdk, but >> I”m not sure how the build works out there. So I’m not sure it’s in docker >> hub yet. >> >> > >> > Not sure how much travis-ci be helpful here since I saw Pascal removed >> > oraclejdk7 from .travis configuration because its not available. I'm not >> > keeping much hopes on Travis at this point as their provision on >> different >> > jdk images seems very slow to me . >> >> I think there was some flavour of issue with Java7 in that the image >> wasn’t loading properly. It could be worth trying the jacoco approach to >> see if that works. >> >> -Rob >> >> > >> > Regards, >> > Amey >> > >> > On Sat, Jul 1, 2017, 6:43 PM Rob Tompkins <chtom...@gmail.com> wrote: >> > >> >> Hello all, >> >> >> >> Pardon my disappearance for the last week or so. My day job has been a >> >> little over consuming (c’est la vie). Regardless, I’ve been looking at >> how >> >> we can use the current appetite in the travis-ci community to push >> them to >> >> install ibmjava8 and ibmjava9 in this working thread: >> >> https://github.com/travis-ci/travis-ci/issues/2682 < >> >> https://github.com/travis-ci/travis-ci/issues/2682>. Hopefully we can >> >> gain some traction there. >> >> >> >> Regardless, they seem to have far more idk’s installed in their build >> >> environment than documented >> >> https://github.com/travis-ci/travis-cookbooks/tree/master/co >> okbooks/travis_java/recipes >> >> < >> >> https://github.com/travis-ci/travis-cookbooks/tree/master/co >> okbooks/travis_java/recipes>. >> >> Which, as Amey noted earlier, jacoco seems to be utilizing >> >> https://github.com/jacoco/jacoco/blob/master/.travis.yml#L14-L23 < >> >> https://github.com/jacoco/jacoco/blob/master/.travis.yml#L14-L23>. >> >> >> >> I’m not particularly looking for any responses to this email. I more >> just >> >> wanted to document my current research efforts here. >> >> >> >> Cheers, >> >> -Rob >> >> >> - >> 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: Fwd: [2/2] commons-cli git commit: add default mvn default (clean, test, clirr, rat and javadoc) and run it on travis
Just checked commons-cli pom.xml and found checkstyle and findbug support is already present in reporting section, just copied same setting in build section and we are good. https://github.com/apache/commons-cli/pull/16 You are welcome :-) Regards, Amey On Tue, Aug 1, 2017 at 11:26 PM, Pascal Schumacher <pascalschumac...@gmx.net > wrote: > Imho yes, but to make this possible existing violations have to be > analyzed and then either fixed or ignored. > > > Am 01.08.2017 um 19:37 schrieb Amey Jadiye: > >> It would be nice to add checkstyle and findbug as well ? >> >> Regards, >> Amey >> >> -- Forwarded message -- >> From: <pascalschumac...@apache.org> >> Date: Tue, Aug 1, 2017 at 10:57 PM >> Subject: [2/2] commons-cli git commit: add default mvn default (clean, >> test, clirr, rat and javadoc) and run it on travis >> To: comm...@commons.apache.org >> >> >> add default mvn default (clean, test, clirr, rat and javadoc) and run it >> on >> travis >> >> >> Project: http://git-wip-us.apache.org/repos/asf/commons-cli/repo >> Commit: http://git-wip-us.apache.org/repos/asf/commons-cli/commit/34 >> fe9e52 >> Tree: http://git-wip-us.apache.org/repos/asf/commons-cli/tree/34fe9e52 >> Diff: http://git-wip-us.apache.org/repos/asf/commons-cli/diff/34fe9e52 >> >> Branch: refs/heads/master >> Commit: 34fe9e5250a1a568b52ba277fdc86314c20aece3 >> Parents: 3637948 >> Author: pascalschumacher <pascalschumac...@gmx.net> >> Authored: Tue Aug 1 19:27:50 2017 +0200 >> Committer: pascalschumacher <pascalschumac...@gmx.net> >> Committed: Tue Aug 1 19:27:50 2017 +0200 >> >> -- >> .travis.yml | 3 +++ >> pom.xml | 1 + >> 2 files changed, 4 insertions(+) >> -- >> >> >> http://git-wip-us.apache.org/repos/asf/commons-cli/blob/34fe >> 9e52/.travis.yml >> -- >> diff --git a/.travis.yml b/.travis.yml >> index 9f73b73..f9d9265 100644 >> --- a/.travis.yml >> +++ b/.travis.yml >> @@ -21,5 +21,8 @@ jdk: >> - openjdk7 >> - oraclejdk8 >> >> +script: >> + - mvn >> + >> after_success: >> - mvn clean test jacoco:report coveralls:report -Ptravis-jacoco >> >> http://git-wip-us.apache.org/repos/asf/commons-cli/blob/34fe9e52/pom.xml >> -- >> diff --git a/pom.xml b/pom.xml >> index cb2e0b4..124163b 100644 >> --- a/pom.xml >> +++ b/pom.xml >> @@ -193,6 +193,7 @@ >> >> >> >> +clean verify apache-rat:check clirr:check >> javadoc:javadoc >> >> >> maven-assembly-plugin >> >> >> >> >> > > - > 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
Fwd: [2/2] commons-cli git commit: add default mvn default (clean, test, clirr, rat and javadoc) and run it on travis
It would be nice to add checkstyle and findbug as well ? Regards, Amey -- Forwarded message -- From: <pascalschumac...@apache.org> Date: Tue, Aug 1, 2017 at 10:57 PM Subject: [2/2] commons-cli git commit: add default mvn default (clean, test, clirr, rat and javadoc) and run it on travis To: comm...@commons.apache.org add default mvn default (clean, test, clirr, rat and javadoc) and run it on travis Project: http://git-wip-us.apache.org/repos/asf/commons-cli/repo Commit: http://git-wip-us.apache.org/repos/asf/commons-cli/commit/34fe9e52 Tree: http://git-wip-us.apache.org/repos/asf/commons-cli/tree/34fe9e52 Diff: http://git-wip-us.apache.org/repos/asf/commons-cli/diff/34fe9e52 Branch: refs/heads/master Commit: 34fe9e5250a1a568b52ba277fdc86314c20aece3 Parents: 3637948 Author: pascalschumacher <pascalschumac...@gmx.net> Authored: Tue Aug 1 19:27:50 2017 +0200 Committer: pascalschumacher <pascalschumac...@gmx.net> Committed: Tue Aug 1 19:27:50 2017 +0200 -- .travis.yml | 3 +++ pom.xml | 1 + 2 files changed, 4 insertions(+) -- http://git-wip-us.apache.org/repos/asf/commons-cli/blob/34fe9e52/.travis.yml -- diff --git a/.travis.yml b/.travis.yml index 9f73b73..f9d9265 100644 --- a/.travis.yml +++ b/.travis.yml @@ -21,5 +21,8 @@ jdk: - openjdk7 - oraclejdk8 +script: + - mvn + after_success: - mvn clean test jacoco:report coveralls:report -Ptravis-jacoco http://git-wip-us.apache.org/repos/asf/commons-cli/blob/34fe9e52/pom.xml -- diff --git a/pom.xml b/pom.xml index cb2e0b4..124163b 100644 --- a/pom.xml +++ b/pom.xml @@ -193,6 +193,7 @@ +clean verify apache-rat:check clirr:check javadoc:javadoc maven-assembly-plugin -- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons Email 1.5 Based on RC1
Hi, I have fixed this, and yes reason was though those .eml files was added in exclusion but in reports and not in build. I have raised PR and tested it on my local. https://github.com/apache/commons-email/pull/2 Regards, Amey On Sun, Jul 30, 2017 at 7:42 PM, Stefan Bodewig <bode...@apache.org> wrote: > On 2017-07-30, Gary Gregory wrote: > > > Branding: The RELEASE-NOTES.txt file should start with "Apache Commons > > Email Package" instead of "Commons Email Package". > > I was under the impression it had been generated by the commons-build > plugin. Anyway, will fix it when I publish the release (no reason to > vote on that). > > > RAT check fails with: > > > Unapproved licenses: > > > src/test/resources/eml/attachment-only.eml > > src/test/resources/eml/html-attachment-content-disposition.eml > > src/test/resources/eml/html-attachment-encoded-filename.eml > > src/test/resources/eml/html-attachment.eml > > src/test/resources/eml/multipart-report.eml > > src/test/resources/eml/multipart-text-attachment-only.eml > > src/test/resources/eml/multipart-text-attachment.eml > > src/test/resources/eml/outofmemory-no-header-seperation.eml > > src/test/resources/eml/simple-reply.eml > > src/test/resources/eml/simple.eml > > The pom contains > > > org.apache.rat > apache-rat-plugin > > > src/test/resources/eml/*.eml > > > > > and RAT is prefectly happy inside the site build. How do you execute the > rat check? Comparing the POM with the one of Compress I see the plugin > is configured inside the section for Email only, while it is > inside for Compress. This may explain the difference when > running rat checks directly. > > Stefan > > - > 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
[email] failing with mvn clean cobertura:cobertura coveralls:report
Hi, while fixing rat issue with commons email I also found that the travis is failing with the below configurations, thought build is working fine. seems like we dont have plugin configured in pom.xml after_success: - mvn clean cobertura:cobertura coveralls:report [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 5.066 s [INFO] Finished at: 2017-07-30T13:15:04+00:00 [INFO] Final Memory: 17M/490M [INFO] [ERROR] No plugin found for prefix 'coveralls' in the current project and in the plugin groups [org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (/home/travis/.m2/repository), central (https://repo.maven.apache.org/maven2)] -> [Help 1] [ERROR] Regards, Amey - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons Email 1.5 Based on RC1
Checked RC1, and here is my +1 (non-binding). 1. Build and Tests looks good. 2. Clirr looks good. 3. Rat is not good as mentioned by gary, as they are test resources can be put to ignore list. 4. Findbug looks good. 5. There are 302 Checkstyle issues but they are non-blocker to release. 6. Hashes looks good. 7. Site looks good. Checked on :- Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T22:11:47+05:30) Maven home: /opt/apache/maven Java version: 1.8.0_111, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-8-oracle/jre Default locale: en_IN, platform encoding: UTF-8 OS name: "linux", version: "4.4.0-31-generic", arch: "amd64", family: "unix" On Sat, Jul 29, 2017 at 7:54 PM, Stefan Bodewigwrote: > We have fixed quite a few bugs and added some significant enhancements > since Email 1.4 was released, so I would like to release Email 1.5. > > Email 1.5 RC1 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/email/ > (svn revision 20667) > > The tag is here: > http://svn.apache.org/repos/asf/commons/proper/email/tags/ > EMAIL_1_5_RC1/ > (svn revision 1803366) > N.B. the SVN revision is required because SVN tags are not immutable. > > Maven artifacts are here: > https://repository.apache.org/content/repositories/ > orgapachecommons-1255/org/apache/commons/commons-email/1.5/ > > These are the Maven artifacts and their SHA1 hashes > > e8e677c6362eba14ff3c476ba63ccb83132dbd52 commons-email-1.5.jar > 6ccc8b44cb666b849b71ecc6fa32549a6461c099 commons-email-1.5-javadoc.jar > 09d31911480b5148275d8a26c60e355bbcbe9ae3 commons-email-1.5.pom > dbe951d1b89eb9472b4b2c8f618b8bc9783b6623 commons-email-1.5-sources.jar > 15afde52264e316438802b5bd05d34bc424bf659 commons-email-1.5-tests.jar > e157492dfd776839387a6ce4af0d191e0a92a534 commons-email-1.5-test- > sources.jar > > I have tested this with JDK 8 using Maven 3.0.5. > > As usual when I cut a release the site is not the one I'll publish > once the vote has succeeded. I'll recreate the site once the release > date is known. > > I've already copied the javadocs for 1.4 so > http://commons.apache.org/proper/commons-email/javadocs/api-1.4/index.html > already is available. The javadoc links and download page certainly > don't work in the staging site. > > Details of changes since 1.4 are in the release notes: > https://dist.apache.org/repos/dist/dev/commons/email/RELEASE-NOTES.txt > https://stefan.samaflost.de/staging/commons-email-1.5/ > changes-report.html > > Site: > https://stefan.samaflost.de/staging/commons-email-1.5/ > > Clirr Report (compared to 1.4): > https://stefan.samaflost.de/staging/commons-email-1.5/ > clirr-report.html > > RAT Report: > https://stefan.samaflost.de/staging/commons-email-1.5/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, > i.e. sometime after 14:30 UTC 1-Aug 2017 > > [ ] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... > > Thanks! > > - > 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/travis-ci] Regarding using ibmjava on travis
Thanks, I'm taking Commons Text as my test guineapig for jacoco style implementation , once confident in implementation we can move it to other components. Regards, Amey On Jul 28, 2017 5:39 PM, "Rob Tompkins" <chtom...@gmail.com> wrote: > > > On Jul 27, 2017, at 4:10 PM, Amey Jadiye <ameyjad...@gmail.com> wrote: > > > > Hi Rob, > > > > If this is still pending I would like to pickup this task. If docker is > not > > much helpful OR we need to wait for it I think we should try what jacoco > > did. what do you think ? > > Sure. That makes sense to me, especially since the Travis folks say that > they’ve got on the backlog to install the IBM JDKs on their build > environments. > > > > > Is it mandatory to use official java images ?Else I am also thinking to > > create my own ibmjdk8 image on top of given by IBM and have some tools > and > > scrips ready in that so on fail it should return -1. > > I contributed to the official maven docker image to add the ibm jdk, but > I”m not sure how the build works out there. So I’m not sure it’s in docker > hub yet. > > > > > Not sure how much travis-ci be helpful here since I saw Pascal removed > > oraclejdk7 from .travis configuration because its not available. I'm not > > keeping much hopes on Travis at this point as their provision on > different > > jdk images seems very slow to me . > > I think there was some flavour of issue with Java7 in that the image > wasn’t loading properly. It could be worth trying the jacoco approach to > see if that works. > > -Rob > > > > > Regards, > > Amey > > > > On Sat, Jul 1, 2017, 6:43 PM Rob Tompkins <chtom...@gmail.com> wrote: > > > >> Hello all, > >> > >> Pardon my disappearance for the last week or so. My day job has been a > >> little over consuming (c’est la vie). Regardless, I’ve been looking at > how > >> we can use the current appetite in the travis-ci community to push them > to > >> install ibmjava8 and ibmjava9 in this working thread: > >> https://github.com/travis-ci/travis-ci/issues/2682 < > >> https://github.com/travis-ci/travis-ci/issues/2682>. Hopefully we can > >> gain some traction there. > >> > >> Regardless, they seem to have far more idk’s installed in their build > >> environment than documented > >> https://github.com/travis-ci/travis-cookbooks/tree/master/ > cookbooks/travis_java/recipes > >> < > >> https://github.com/travis-ci/travis-cookbooks/tree/master/ > cookbooks/travis_java/recipes>. > >> Which, as Amey noted earlier, jacoco seems to be utilizing > >> https://github.com/jacoco/jacoco/blob/master/.travis.yml#L14-L23 < > >> https://github.com/jacoco/jacoco/blob/master/.travis.yml#L14-L23>. > >> > >> I’m not particularly looking for any responses to this email. I more > just > >> wanted to document my current research efforts here. > >> > >> Cheers, > >> -Rob > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [all/travis-ci] Regarding using ibmjava on travis
Hi Rob, If this is still pending I would like to pickup this task. If docker is not much helpful OR we need to wait for it I think we should try what jacoco did. what do you think ? Is it mandatory to use official java images ?Else I am also thinking to create my own ibmjdk8 image on top of given by IBM and have some tools and scrips ready in that so on fail it should return -1. Not sure how much travis-ci be helpful here since I saw Pascal removed oraclejdk7 from .travis configuration because its not available. I'm not keeping much hopes on Travis at this point as their provision on different jdk images seems very slow to me . Regards, Amey On Sat, Jul 1, 2017, 6:43 PM Rob Tompkins <chtom...@gmail.com> wrote: > Hello all, > > Pardon my disappearance for the last week or so. My day job has been a > little over consuming (c’est la vie). Regardless, I’ve been looking at how > we can use the current appetite in the travis-ci community to push them to > install ibmjava8 and ibmjava9 in this working thread: > https://github.com/travis-ci/travis-ci/issues/2682 < > https://github.com/travis-ci/travis-ci/issues/2682>. Hopefully we can > gain some traction there. > > Regardless, they seem to have far more idk’s installed in their build > environment than documented > https://github.com/travis-ci/travis-cookbooks/tree/master/cookbooks/travis_java/recipes > < > https://github.com/travis-ci/travis-cookbooks/tree/master/cookbooks/travis_java/recipes>. > Which, as Amey noted earlier, jacoco seems to be utilizing > https://github.com/jacoco/jacoco/blob/master/.travis.yml#L14-L23 < > https://github.com/jacoco/jacoco/blob/master/.travis.yml#L14-L23>. > > I’m not particularly looking for any responses to this email. I more just > wanted to document my current research efforts here. > > Cheers, > -Rob
Re: [ALL] Moving view on builds.a.o
Hi, Seems like we are not the only defaulters ;-) ... https://builds.apache.org/ Below resources might be helpful to move Commons top level view to nested view, you might need admin access to do that. https://isticatedcoder.wordpress.com/2015/10/05/structure-jenkins-with-nested-views/ https://isticatedcoder.files.wordpress.com/2015/09/nview.png Regards, Amey On Thu, Jul 27, 2017 at 12:23 AM, Rob Tompkins <chtom...@gmail.com> wrote: > Happy to do it, but I don't have the correct permissions. > > > On Jul 26, 2017, at 2:10 PM, Gary Gregory <garydgreg...@gmail.com> > wrote: > > > > Hi All: > > > > Does anyone know how to move our view? > > > > Please see the warning on https://builds.apache.org/ > view/Apache%20Commons/ > > > > 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
Re: [collections][proposal] Java 7
+1 Regards, Amey On Wed, Jul 26, 2017, 3:48 AM Gary Gregory <garydgreg...@gmail.com> wrote: > Hi All: > > I propose we make Java 7 the minimum for Commons Collection 4.2. > > Gary >
Re: [ANNOUNCE] Apache Commons Collections moved to git
BTW, I just sorted all proper components and below is the list of component still using svn, seems quit a lot work still remaining ;-) bcel | http://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0 bcel beanUtils |http://svn.apache.org/viewvc/commons/proper/beanutils/trunk/ bsf|http://svn.apache.org/repos/asf/commons/proper/bsf/trunk build-plugin| http://svn.apache.org/viewvc/commons/proper/commons-build-plugin/trunk chain|http://svn.apache.org/viewvc/commons/proper/chain/trunk codec|http://svn.apache.org/viewvc/commons/proper/codec/trunk configuration| http://svn.apache.org/viewvc/commons/proper/configuration/trunk daemon|http://svn.apache.org/viewvc/commons/proper/daemon/trunk digester|http://svn.apache.org/viewvc/commons/proper/digester/trunk discovery|http://svn.apache.org/viewvc/commons/proper/discovery/trunk email|http://svn.apache.org/viewvc/commons/proper/email/trunk exec|http://svn.apache.org/viewvc/commons/proper/exec/trunk functor|http://svn.apache.org/viewvc/commons/proper/functor/trunk/ jci|http://svn.apache.org/viewvc/commons/proper/jci/trunk/ jcs|http://svn.apache.org/viewvc/commons/proper/jcs/tags/commons-jcs-2.1 jexl|http://svn.apache.org/viewvc/commons/proper/jexl/tags/COMMONS_JEXL_3_1 jxpath|http://svn.apache.org/repos/asf/commons/proper/jxpath/trunk launcher|http://svn.apache.org/repos/asf/commons/proper/jxpath/trunk logging|http://svn.apache.org/repos/asf/commons/proper/logging/trunk net|http://svn.apache.org/viewvc/commons/proper/net/tags/NET_3_6 ognl|http://svn.apache.org/viewvc/commons/proper/ognl/trunk/ pool|http://svn.apache.org/viewvc/commons/proper/pool/trunk proxy|http://svn.apache.org/repos/asf/commons/proper/proxy/trunk/ transaction|http://svn.apache.org/viewvc/commons/proper/transaction/trunk validator| http://svn.apache.org/viewvc/commons/proper/validator/tags/VALIDATOR_1_6/ vfs| http://svn.apache.org/viewvc/commons/proper/vfs/tags/commons-vfs2-project-2.1 weaver|http://svn.apache.org/viewvc/commons/proper/weaver/trunk/ Regards, Amey On Wed, Jul 19, 2017 at 5:46 PM, Rob Tompkins <chtom...@gmail.com> wrote: > > > > On Jul 19, 2017, at 8:13 AM, Stefan Bodewig <bode...@apache.org> wrote: > > > > On 2017-07-19, Rob Tompkins wrote: > > > >> The Apache Commons Collections component has been moved to git. > > > > Many thanks for doing that, Rob! > > > > Are you following some kind of playbook with the git migration? If so, > > we should add one point: > > > > * edit the svn:externals property of > > https://svn.apache.org/repos/asf/commons/trunks-proper and remove the > > entry for the component just migrated. > > Good point, and no playbook here. I suppose we should either: 1. create such a playbook, or 2. do the remainder of the repos so that such a playbook is no longer needed. :-) > > > > > Cheers > > > >Stefan > > > > - > > 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] Removal of old pgp key from https://www.apache.org/dist/commons/KEYS
fair enough not to remove keys ;) , Thanks. Regards, Amey On Wed, Jul 19, 2017, 1:32 AM Stefan Bodewig <bode...@apache.org> wrote: > On 2017-07-18, Amey Jadiye wrote: > > > I observed we have lot of keys in > https://www.apache.org/dist/commons/KEYS, > > even keys of developers who might have resigned from commons, can we just > > review and remove keys of developers who resigned or no more active ? > > We shouldn't remove any key that has been used to sign a release in the > past. No matter how long in the past :-) > > Stefan > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [all] Removal of old pgp key from https://www.apache.org/dist/commons/KEYS
How about developers who resigned ? It means whoever sent mail that they are not willing to be the part of community.? I think keeping keys of non-active developers of Ok. Ex. James have resigned http://commons.markmail.org/message/i2davy3nf4fr7xqp But I can see his key. pub 1024D/9EEDB2D5 2006-04-14 uid James Carman <jcar...@apache.org> sig 39EEDB2D5 2006-04-14 James Carman <jcar...@apache.org> sub 2048g/4240E713 2006-04-14 sig 9EEDB2D5 2006-04-14 James Carman <jcar...@apache.org> Also I see lot of people resigned here http://commons.markmail.org/message/2fzh5qgwhppkdslj Regards, Amey On Tue, Jul 18, 2017 at 11:55 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > There is no criteria for "not active"; either you are a committer or you > are not per: https://people.apache.org/phonebook.html?unix=commons > > Gary > > On Tue, Jul 18, 2017 at 11:21 AM, Amey Jadiye <ameyjad...@gmail.com> > wrote: > > > I observed we have lot of keys in https://www.apache.org/dist/ > commons/KEYS > > , > > even keys of developers who might have resigned from commons, can we just > > review and remove keys of developers who resigned or no more active ? > > > > Regards, > > Amey > > > > - > > 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] Removal of old pgp key from https://www.apache.org/dist/commons/KEYS
I observed we have lot of keys in https://www.apache.org/dist/commons/KEYS, even keys of developers who might have resigned from commons, can we just review and remove keys of developers who resigned or no more active ? Regards, Amey - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons DbUtils 1.7 based on RC2
Checked RC2, and here is my +1 (non-binding). 1. Build and Tests are passing clean 2. Clirr and Rat looks good. 3. Findbug show two DM_DEFAULT_ENCODING warning but non-blocker to release. 3. There are few of bugs in Checkstyle report but they are non-blocker to release. 4. Hashes given in files looks good. 5. Site looks fine. I observed we have quite a lot keys in https://www.apache.org/dist/commons/KEYS, even developers who might have resigned from commons, can we just remove keys of developers who resigned or no more active ? Checked on :- Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T22:11:47+05:30) Maven home: /opt/apache/maven Java version: 1.8.0_111, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-8-oracle/jre Default locale: en_IN, platform encoding: UTF-8 OS name: "linux", version: "4.4.0-31-generic", arch: "amd64", family: "unix" Regards, Amey On Mon, Jul 17, 2017 at 4:11 AM, Carl Hall <carl.h...@gmail.com> wrote: > Hi, > > It's been almost 3 years to the day since we've had a DbUtils release. > We've fixed several important bugs and added some new features, so I would > like to release DbUtils 1.7. > > Furthermore, we have fixed these issues for RC2, which were discovered in > RC1: > - resource leaks as found by FindBugs > - updated links & text in generated texts and site > > DbUtils 1.7 RC2 is available for review here: >https://dist.apache.org/repos/dist/dev/commons/dbutils/DBUTILS_1_7_RC2/ > (svn > revision 20455) > > The tag is here: >*https://git-wip-us.apache.org/repos/asf?p=commons-dbutils.git;a=tag;h= > c7b9d1229aeacd1884c9ca126c5d65af0221404a > <https://git-wip-us.apache.org/repos/asf?p=commons-dbutils.git;a=tag;h= > c7b9d1229aeacd1884c9ca126c5d65af0221404a>* > > Maven artifacts are here: >https://repository.apache.org/content/repositories/ > orgapachecommons-1254 > > These are the Maven Artifacts and their hashes: > > commons-dbutils-1.7-javadoc.jar > (SHA: 23ba15ea4ff18419fb17715e8956846b863c2d9d) > commons-dbutils-1.7-javadoc.jar.asc > (SHA: fb5f36b61e056c31ea3181c0a67c9bf395cd56e0) > commons-dbutils-1.7-javadoc.jar.md5 > (SHA: daae48f032e6f96a63c8b47241de7fae7c53e176) > commons-dbutils-1.7-javadoc.jar.sha1 > (SHA: 092fbb145d61a4d93dd645a529e212fe01099d14) > commons-dbutils-1.7-sources.jar > (SHA: 38e00df900c6c0dd01dec42ad411ff44de10ac0b) > commons-dbutils-1.7-sources.jar.asc > (SHA: 601b900b1a6079c09a81da903f0bd418dc552f09) > commons-dbutils-1.7-sources.jar.md5 > (SHA: 1fce7ad72fc18d639705a1573c34cc012e076a25) > commons-dbutils-1.7-sources.jar.sha1 > (SHA: 198663d496d62b4f78ab8edf85c7125e79213f32) > commons-dbutils-1.7-test-sources.jar > (SHA: 6c61c9324218009db50415bfdf8b1c6675dcbbf0) > commons-dbutils-1.7-test-sources.jar.asc > (SHA: 120cd3f4f4d673eb49cd976f814110a74bde438f) > commons-dbutils-1.7-test-sources.jar.md5 > (SHA: 135c8c5dd7c868c116d17dc694731ff6230270f7) > commons-dbutils-1.7-test-sources.jar.sha1 > (SHA: 38d6480819b9d813ad18307349a19603ed53f453) > commons-dbutils-1.7-tests.jar > (SHA: be58f64000d4b5a5932f5c18afbb847b3fe6caf3) > commons-dbutils-1.7-tests.jar.asc > (SHA: b93e9d1b23bbf051630b60ba917af03f0fd2a8cc) > commons-dbutils-1.7-tests.jar.md5 > (SHA: beb09dfdd239b5a09d96132546e6a9cb5899617e) > commons-dbutils-1.7-tests.jar.sha1 > (SHA: d25629f7ea7d3e352ad98f6d955ce473606d3ecf) > commons-dbutils-1.7.jar > (SHA: 8b750837334b0c92f3f09a481ff6638aa0a7e370) > commons-dbutils-1.7.jar.asc > (SHA: bbd4a9cdb128233e2bf67c252789385091576a6c) > commons-dbutils-1.7.jar.md5 > (SHA: 5b90d74d0967dcb3ba4422489910730c3ff396b5) > commons-dbutils-1.7.jar.sha1 > (SHA: ecb00abbc04548398986b80d1f0e48373d55c2b8) > commons-dbutils-1.7.pom > (SHA: dcaebe462df8501f14d764f2bece496e942586eb) > commons-dbutils-1.7.pom.asc > (SHA: 0547d14d07117cc496c018ef7fd320ae32884287) > commons-dbutils-1.7.pom.md5 > (SHA: c5a32289a952a40202461528eeffcad474d0ef6c) > commons-dbutils-1.7.pom.sha1 > (SHA: 0aa622dc6fa860ceeaf86fcb3e1a48f9530c3398) > > Details of changes since 1.6 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/dbutils/ > DBUTILS_1_7_RC2/RELEASE-NOTES.txt >https://home.apache.org/~thecarlhall/dbutils-1.7-RC2/ > changes-report.html > > Site: >https://home.apache.org/~thecarlhall/dbutils-1.7-RC2/ > > Clirr Report (compared to 1.6): >https://home.apache.org/~thecarlhall/dbutils-1.7-RC2/clirr-report.html > >- All changes are additions and do not represent any fundamental or > breaking changes in how to use the library, so not revving the version. > > RAT Report: >https://home.apache.org/~thecarlhall/dbutils-1.7-RC2/rat-report.html > > KEYS: >https
Re: [lang][collections] SortedProperties
My opinion is this should go to *lang* because the fact is it's extended utility and not exactly as data structures though it looks like one. It's main purpose is to hold properties and not the data. Commons collection aims to provide utlilities and extension to data structures and not to properties related utilities. Properties is very basic thing no matter it's sorted or not sorted and should go to lang. Regards, Amey On Tue, Jul 18, 2017, 11:58 AM Gary Gregory <garydgreg...@gmail.com> wrote: > Hi, > > I'd to have a new class called SortedProperties that extends > java.util.Properties. > > Should that go in [lang] or [collections]? > > I first thought [lang], but it _is_ a collection after all. > > Gary >
Re: [daemon] moving to git ? and bump java version.
Hi Gary, I will take a look at pending issues if something is blocker to release, I see already 9 issues are done for 1.1.0 release . if we are ok with these 9, anyone can release it. BTW how do you guys decide that "this is a time to release!" for any component ? Regards, Amey On Jul 16, 2017 10:38 PM, "Gary Gregory" <garydgreg...@gmail.com> wrote: > If someone here is really going to put time and energy into daemon, it > would be fantastic to start with a release. It's been so long... Then > fiddle away on tweaks, and release again. > > Gary > > On Jul 16, 2017 08:49, "Matt Sicker" <boa...@gmail.com> wrote: > > > C quality somewhat depends on which version of C you're trying to remain > > compatible with (I'm guessing C89 due to Windows, though I could be > wrong). > > Valgrind and other tracing tools are typically used. I'd take a look at > > what OpenOffice is doing for local examples (though they have a crazy > build > > system last I heard), or the FSF, Linux, Xorg, FreeDesktop, GNOME, KDE, > or > > other major users of C and C++. > > > > On the modern front, it'd be interesting if it were written in Rust, > though > > I don't know enough about the language to say if it's worth porting to > > eventually. > > > > On 15 July 2017 at 09:26, sebb <seb...@gmail.com> wrote: > > > > > On 15 July 2017 at 15:21, Amey Jadiye <ameyjad...@gmail.com> wrote: > > > > Yes, that's mentioned in my previous mail, I was also curious to > know > > > from > > > > the C developers here in dev-list that how can we make *that* C code > > > > better? basically I'm looking findbug, checkstyle, jococo, junit > > > > *equivalent* for C code. > > > > > > No idea on automated tools. > > > However when I last looked there was plenty of scope for better > > > documentation. > > > > > > Also I did wonder if the Prunmgr GUI might be better coded as a > > > (mainly) Java application. > > > > > > The procrun stuff has to remain as C. > > > > > > > Regards, > > > > Amey > > > > > > > > On Sat, Jul 15, 2017 at 7:44 PM, sebb <seb...@gmail.com> wrote: > > > > > > > >> Also note that there is hardly any Java code; most of it is written > in > > > C. > > > >> > > > >> On 14 July 2017 at 00:43, Gary Gregory <garydgreg...@gmail.com> > > wrote: > > > >> > It seems OK to me to update to Java 6 for now and get this to > > compile > > > >> under > > > >> > java 9 for those folks who will try... > > > >> > > > > >> > Gary > > > >> > > > > >> > On Wed, Jul 12, 2017 at 9:09 AM, Amey Jadiye < > ameyjad...@gmail.com> > > > >> wrote: > > > >> > > > > >> >> Thanks for great insights Mark. > > > >> >> > > > >> >> On Wed, Jul 12, 2017, 9:28 PM Mark Thomas <ma...@apache.org> > > wrote: > > > >> >> > > > >> >> > On 12 July 2017 16:33:01 CEST, Matt Sicker <boa...@gmail.com> > > > wrote: > > > >> >> > >Are there plans to require 1.7 for Tomcat anytime? Otherwise, > it > > > >> might > > > >> >> > >be > > > >> >> > >necessary to make a new major version of daemon eventually for > > > Java 8 > > > >> >> > >or 9. > > > >> >> > > > > >> >> > Tomcat major versions are aligned with Java EE versions which > in > > > turn > > > >> >> have > > > >> >> > a minimum Java version. > > > >> >> > > > > >> >> > Tomcat supports 3 current versions in parallel so we currently > > > have: > > > >> >> > > > > >> >> > Tomcat 9 - Java EE 8 - Java 8 > > > >> >> > Tomcat 8 - Java EE 7 - Java 7 > > > >> >> > Tomcat 7 - Java EE 6 - Java 6 > > > >> >> > > > > >> >> > Tomcat 7 support will continue until at least Java EE 9 is > > > released. > > > >> That > > > >> >> > is meant to be next year but there are no firm dates yet and > > > >> experience > > > >> >> > suggests the Java EE 9 release date will sli
Re: [lang] - Remove RandomStringUtils deprecation / move it to [text]?
Thanks, I will raise PR soon, and for this we don't have to wait for 2.x , that's good part. Regards, Amey On Sun, Jul 16, 2017, 3:41 PM Pascal Schumacher <pascalschumac...@gmx.net> wrote: > Hello Amey, > > that seems to be the cleanest solution (although the one requiring the > most work). > > Cheers, > Pascal > > Am 14.07.2017 um 18:59 schrieb Amey Jadiye: > > Hello Pascal, > > > > Thanks for putting this on table, I too think that users need some short > > code to show up output really quick. > > > > How about this plan :- > > > > 1. Keep RandomStringUtils deprecated in commons-lang. > > 2. Move RandomStringUtils class to commons-text. > > 3. Remove all existing code from methods of RandomStringUtils and call > our > > brand new RandomStringGenerator in them. to return respective values i.e. > > randomNumeric, randomAlphabetic, randomAlphanumeric etc > > > > Its obvious question "what we will achieve with this ?" > > > > So, we are still promoting the RandomStringGenerator this should be the > > base of all random string generator methods. > > since RandomStringGenerator very flexible we can keep the functionalities > > from RandomStringUtils untouched and can retain users who are still > > addicted to same class and API of RandomStringUtils, else users will not > > accept new and bit cumbersome (with their perspective) > > RandomStringGenerator and stick to old code. > > > > The user who want bit more flexibility are still welcome to use > > RandomStringGenerator anyway. > > > > Regards, > > Amey > > > > > > On Fri, Jul 14, 2017 at 1:32 AM, Pascal Schumacher < > pascalschumac...@gmx.net> > > wrote: > >> Hello everybody, > >> > >> with 3.5 we deprecated RandomStringUtils in favor of > > RandomStringGenerator in commons-text. > >> https://issues.apache.org/jira/browse/TEXT-96 complains that > > "RandomStringGenerator is extremely verbose compared to the deprecated > > commons.lang3 RandomStringUtils." > >> From my experience taking a look at migrating a project from > > RandomStringUtils to RandomStringGenerator I have to agree. Some > > convenience methods will be added with the next commons text release, but > > it still won't be as easy to use as RandomStringUtils. For course > > RandomStringGenerator gives the user more options, but most usage of > > RandomStringUtils I have seen was just for tests or other simple > use-cases > > where these option are not required. > >> Maybe we should just remove the RandomStringUtils deprecation or add the > > whole class untouched to commons-text? > >> What do you think? > >> > >> Cheers, > >> > >> Pascal > >> > > - > > 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 DbUtils 1.7 based on RC1
Build and Tests are passing clean, clirr and rat looks good. there are few of bugs in findbug and checkstyle report but they are non-blocker to release. hashes looks good. site looks fine. Here is my +1 to release (non-binding) Checked on :- Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T22:11:47+05:30) Maven home: /opt/apache/maven Java version: 1.8.0_111, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-8-oracle/jre Default locale: en_IN, platform encoding: UTF-8 OS name: "linux", version: "4.4.0-31-generic", arch: "amd64", family: "unix" Regards, Amey On Sun, Jul 16, 2017 at 10:46 AM, Carl Hall <carl.h...@gmail.com> wrote: > Hi, > > It's been almost 3 years to the day since we've had a DbUtils release. > We've fixed several important bugs and added some new features, so I would > like to release DbUtils 1.7. > > DbUtils 1.7 RC1 is available for review here: >https://dist.apache.org/repos/dist/dev/commons/dbutils/DBUTILS_1_7_RC1/ > (svn revision 20453) > > The tag is here: > > https://git-wip-us.apache.org/repos/asf?p=commons-dbutils.git;a=tag;h= > 5cac6914f8c41c0a3a7daa524b581e2bb991475c > > Maven artifacts are here: >https://repository.apache.org/content/repositories/ > orgapachecommons-1253 > > These are the Maven Artifacts and their hashes: > > commons-dbutils-1.7-javadoc.jar > (SHA: e22dd333bf755f89c0a12d8fe8e9f9791f4d584d) > commons-dbutils-1.7-javadoc.jar.asc > (SHA: dca6226d3474a3cdfbf0981cd77fd6eca98d423c) > commons-dbutils-1.7-javadoc.jar.md5 > (SHA: 8b5918304c84a8bc3d91bff24450350c8a21cdd6) > commons-dbutils-1.7-javadoc.jar.sha1 > (SHA: 7b652e50d72f1df3258e2b1def4811bc2c990414) > commons-dbutils-1.7-sources.jar > (SHA: b8046fc31bad05ceac0b239813490e7318cf6688) > commons-dbutils-1.7-sources.jar.asc > (SHA: b8254614b870b3e603649051622ff6e973c8877e) > commons-dbutils-1.7-sources.jar.md5 > (SHA: 86874a2f66ba9c6990a364a156fbc96490221808) > commons-dbutils-1.7-sources.jar.sha1 > (SHA: f055e9526b0d6452179025413ea2a232e8edaec5) > commons-dbutils-1.7-test-sources.jar > (SHA: 1fd6447ed463463b4f5a8bc22197716d3ec7e03c) > commons-dbutils-1.7-test-sources.jar.asc > (SHA: 46e7e98a6a08ae7656e71b0e1bfe95ff8fa7233b) > commons-dbutils-1.7-test-sources.jar.md5 > (SHA: cc31e5341d12a0c0ac4b5ebe8449b2318033ec6a) > commons-dbutils-1.7-test-sources.jar.sha1 > (SHA: 5a3623034caf69ade14962e1d68259c8781129d0) > commons-dbutils-1.7-tests.jar > (SHA: d0ecec11d46f69e4e4a13be5086b6e3ca40d83d6) > commons-dbutils-1.7-tests.jar.asc > (SHA: a3c72df421a5281a71b83dcb1c555775f11c2669) > commons-dbutils-1.7-tests.jar.md5 > (SHA: efd95070aabcab80b6c1dccb598d9defea838964) > commons-dbutils-1.7-tests.jar.sha1 > (SHA: 14663f80390bf0f1019e7b66579b79cb6abe5609) > commons-dbutils-1.7.jar > (SHA: c7e3e0fafc8960018f7a8604072ba8966021b8cd) > commons-dbutils-1.7.jar.asc > (SHA: f01c0750400d95a7c2bbe12745297f35cf3fde6c) > commons-dbutils-1.7.jar.md5 > (SHA: 5ad0e7594828d40ba91f162fe7a9992f321cc6b9) > commons-dbutils-1.7.jar.sha1 > (SHA: cc8f04f4ef3d9e651ebac7bdadf97c66f3598a19) > commons-dbutils-1.7.pom > (SHA: cc034176a8f7c78eda5aeec467756d87913d80ec) > commons-dbutils-1.7.pom.asc > (SHA: 436a8f12de783feb5c0a37eeb68bd93f19fc567d) > commons-dbutils-1.7.pom.md5 > (SHA: 4b24897d385d2f6ba8c88dbe3d2c0e9afd89247a) > commons-dbutils-1.7.pom.sha1 > (SHA: a3365107285401b8f37352ea013b54f4d052b7c2) > > Details of changes since 1.6 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/dbutils/ > DBUTILS_1_7_RC1/RELEASE-NOTES.txt > https://home.apache.org/~thecarlhall/dbutils-1.7-RC1/changes-report.html > > Site: > https://home.apache.org/~thecarlhall/dbutils-1.7-RC1/ > > Clirr Report (compared to 1.6): > https://home.apache.org/~thecarlhall/dbutils-1.7-RC1/clirr-report.html > > All changes are additions and do not represent any fundamental or > breaking changes in how to use the library, so not revving the version. > > RAT Report: > https://home.apache.org/~thecarlhall/dbutils-1.7-RC1/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, > i.e. sometime after 06:00 UTC 19-July-2017 > > [ ] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... > > Thanks! > > Carl > -- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org