Re: [VOTE] Release Apache Commons Text 1.9 based on RC1

[Amey Jadiye]

+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
>
> git clone https://gitbox.apache.org/repos/asf/commons-text.git --branch
> commons-text-1.9-RC1 commons-text-1.9-RC1
> cd commons-text-1.9-RC1
>
> 2) Check Apache licenses
>
> This step is not required if the site includes a RAT report page which you
> then must check.
>
> mvn apache-rat:check
>
> 3) Check binary compatibility
>
> Older components still use Apache 

Re: [Text] do we have number to word converter ?

[Amey Jadiye]

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 ?

[Amey Jadiye]

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

[Amey Jadiye]

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

[Amey Jadiye]

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)

[Amey Jadiye]

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)

[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".

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.

[Amey Jadiye]

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 ?

[Amey Jadiye]

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

[Amey Jadiye]

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

[Amey Jadiye]

+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

[Amey Jadiye]

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

[Amey Jadiye]

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

[Amey Jadiye]

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

[Amey Jadiye]

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 ?

[Amey Jadiye]

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 ?

[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).

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 ?

[Amey Jadiye]

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 ?

[Amey Jadiye]

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

[Amey Jadiye]

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

[Amey Jadiye]

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 (compared to 2.6):
>
> https://dist.apache.org/repos/dist/dev/commons/io/2.7-RC1/site/japicmp.html
>
> RAT Report:
>
>
> https://dist.apache.org/repos/dist/dev/commons/io/2.7-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 

Re: [all] How PRs could be better

[Amey Jadiye]

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

[Amey Jadiye]

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.)
>
> JApiCmp Report (compared to 1.7):
>
>
> https://dist.apache.org/repos/dist/dev/commons/csv/1.8-RC2/site/japicmp.html
> This release fixes serialization compatibility of CSVRecord with
> versions 1.0 to 1.6. New fields added since
> 1.7 are not serialized. Support for Serializable is scheduled to be
> removed in version 2.0.
>
> RAT Report:
>
>
> 

Re: [VOTE] Release Apache Commons DbUtils 1.8 based on RC2

[Amey Jadiye]

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/repos/dist/dev/commons/dbutils/1.8-RC2/site/changes-report.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/dbutils/1.8-RC2/site/index.html
> (note some *relative* links are broken and the 1.8 directories are not
> yet created - these will be 

Re: [All] Sonarcloud reports zero coverage

[Amey Jadiye]

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

[Amey Jadiye]

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

[Amey Jadiye]

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

[Amey Jadiye]

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

[Amey Jadiye]

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

[Amey Jadiye]

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 includes a RAT report page which you
> then must check.
>
> mvn apache-rat:check
>
> 3) Check binary compatibility
>
> Newer components use JApiCmp with the japicmp Maven Profile:
>
> This step is not required if the site includes a JApiCmp report page which
> you then must check.
>
> mvn install -DskipTests -P japicmp japicmp:cmp
>
> 4) Build the package
>
> mvn -V clean package
>
> You can record 

Re: [CLI] Option arguments without - or --

[Amey Jadiye]

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

[Amey Jadiye]

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

[Amey Jadiye]

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@

[Amey Jadiye]

+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

[Amey Jadiye]

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

[Amey Jadiye]

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

[Amey Jadiye]

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:
> > >> 
> > >> 
> > >> 
> > >>
> https://gitbox.apache.org/repos/asf?p=commons-collections.git;a=commit;h=77e37dbf238d26351edb29e95391e3df75095d01
> > >> 
> > >>  Commit ID the tag points at:
> > >> 77e37dbf238d26351edb29e95391e3df75095d01
> > >> 
> > >>  Site:
> > >> 
> > >> 
> > >> 
> > >>
> https://dist.apache.org/repos/dist/dev/commons/collections/4.3-RC2/site/index.html
> > >> >>>
> > >> >>> The Clirr report is still a problem:
> > >> >>>
> > >> >>>
> > >> >>>
> > >>
> https://dist.apache.org/repos/dist/dev/commons/collections/4.3-RC2/site/clirr-report.html
> > >> >>>
> > >> >>> [The same errors are reported on my machine, so it's
> > >> >>> not a cache issue...]
> > >> >>>
> > >> >>> Regards,
> > >> >>> Gilles
> > >> >>>
> > >> 
> > >>  Distribution files (committed at revision 31689):
> > >>    https://dist.apache.org/repos/dist/dev/commons/collections/
> > >> 
> > >>  Distribution files hashes (SHA256):
> > >>   commons-collections4-4.3-bin.tar.gz
> > >> 
> > >> 214c12fae27403f1a16ca6c108b5a8682be1a885a0dbbfc8eb30941303e1fe94
> > >>   commons-collections4-4.3-bin.zip
> > >> 
> > >> 75b51a98fea6fca3746a3f70c6a0be24c99849e4976c4649214eaa5a009d0aeb
> > >>   commons-collections4-4.3-src.tar.gz
> > >> 
> > >> 399f403feca86dbba7c4162eb90174db45979a2f7db2b3e0ba48240dc43ab434
> > 

Re: [VOTE] Release Apache Commons Text 1.5 based on RC3

[Amey Jadiye]

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)

[Amey Jadiye]

+1, STATISTICS.

Regards,
Amey

On Thu, Jan 11, 2018, 5:42 AM Gilles  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 
> >>> 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

[Amey Jadiye]

How about Commons Statistics ?, Sounds descriptive.

Regards,
Amey

On Tue, Jan 2, 2018, 4:55 PM Gilles  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

[Amey Jadiye]

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

[Amey Jadiye]

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

[Amey Jadiye]

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

[Amey Jadiye]

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

> On Tue, 12 Sep 2017 13:07:24 +0200, Jochen Wiedmann wrote:
>
>> On Sat, Sep 2, 2017 at 12:50 AM, Gilles 
>> 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

[Amey Jadiye]

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

[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  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  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 
>>> 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 , @PascalSchumacher
 , and @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
 ,
 or mute the thread
 
 .

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

[Amey Jadiye]

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 
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
> >  > c0665804fadcfb6f9f37048efee#commitcomment-24498832>,
> > or mute the thread
> >  > 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

[Amey Jadiye]

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

[Amey Jadiye]

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

[Amey Jadiye]

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 
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 
> 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,  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 
> >> Authored: Fri Sep 22 13:24:00 2017 -0400
> >> Committer: Rob Tompkins 
> >> 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?

[Amey Jadiye]

+1, LGTM.

Regards,
Amey

On Mon, Sep 18, 2017, 3:24 PM Benedikt Ritter  wrote:

> Hi,
>
> I just became aware of 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"

[Amey Jadiye]

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

[Amey Jadiye]

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

[Amey Jadiye]

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

[Amey Jadiye]

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

[Amey Jadiye]

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

[Amey Jadiye]

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

[Amey Jadiye]

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

Re: [VOTE] Release Commons Jelly 1.0.1 based on RC3.

[Amey Jadiye]

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.

[Amey Jadiye]

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.

[Amey Jadiye]

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  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 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/junit/jars/junit-3.8.1.jar
> Warning: directory
>  13  118k   13 161580 0  40580  0  0:00:02 --:--:--  0:00:02
> 

Re: [VOTE] Release Apache Commons CSV 1.5 based on RC1

[Amey Jadiye]

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

[Amey Jadiye]

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

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

[Amey Jadiye]

+1

On Sun, Aug 20, 2017 at 3:44 PM, Pascal Schumacher  wrote:

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

[Amey Jadiye]

+1

On Sun, Aug 20, 2017 at 3:41 PM, Pascal Schumacher  wrote:

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

[Amey Jadiye]

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

[Amey Jadiye]

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

[Amey Jadiye]

+1, If something is/will not in use better delete them.

Cheers,
Amey

On Sun, Aug 13, 2017, 11:54 PM Pascal Schumacher 
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?

[Amey Jadiye]

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

> I thought we already had a new view, I guess not :-(
>
> Gary
>
> On Wed, Aug 9, 2017 at 5:17 PM, Gilles 
> 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 ?

[Amey Jadiye]

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 ?

[Amey Jadiye]

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

[Amey Jadiye]

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

[Amey Jadiye]

+1 (non-binding)

On Wed, Aug 2, 2017 at 7:02 PM, Thomas Vandahl  wrote:

> 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

[Amey Jadiye]

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

[Amey Jadiye]

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

[Amey Jadiye]

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 
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 install' with both JDK
> 1.6 and 1.7 was successful (on Windows 10).
>
> A timing issue?
>
> Oliver
>
> >
> > [INFO]
> > 

Re: [all/travis-ci] Regarding potential Travis-CI solutions

[Amey Jadiye]

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

Re: [RNG] Generating for nums

[Amey Jadiye]

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

[Amey Jadiye]

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

[Amey Jadiye]

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

[Amey Jadiye]

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

[Amey Jadiye]

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

[Amey Jadiye]

It would be nice to add checkstyle and findbug as well ?

Regards,
Amey

-- Forwarded message --
From: 
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 
Authored: Tue Aug 1 19:27:50 2017 +0200
Committer: pascalschumacher 
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

[Amey Jadiye]

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

[Amey Jadiye]

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

[Amey Jadiye]

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 Bodewig  wrote:

> 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

[Amey Jadiye]

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

[Amey Jadiye]

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

[Amey Jadiye]

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

> Happy to do it, but I don't have the correct permissions.
>
> > On Jul 26, 2017, at 2:10 PM, Gary Gregory 
> 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

[Amey Jadiye]

+1

Regards,
Amey

On Wed, Jul 26, 2017, 3:48 AM Gary Gregory  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

[Amey Jadiye]

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  wrote:
>
>
> > On Jul 19, 2017, at 8:13 AM, Stefan Bodewig  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

[Amey Jadiye]

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

[Amey Jadiye]

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

[Amey Jadiye]

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

[Amey Jadiye]

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  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
>  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://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 23: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
>

Re: [lang][collections] SortedProperties

[Amey Jadiye]

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

[Amey Jadiye]

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

[Amey Jadiye]

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

[Amey Jadiye]

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