Re: [io] Make requirement Java 7?

+1 On Apr 25, 2016 11:53 PM, "Gary Gregory" wrote: > Does anyone object updating [io] to Java 7? > > I have a coupe of utils that sit on top of Java 7 IO classes I'd like to > include. > > Gary > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second

Re: [CRYPTO] Switch from JNI to JNA

I like it. RERO! As we plan to have release sooner, marking release ALPHA tagged make sense IMO. Regards, Uma On 4/25/16, 7:02 PM, "sebb" wrote: >On 26 April 2016 at 02:56, Chen, Haifeng wrote: Sounds like a tough time schedule. It's only one week until May. >> Yeah, it's a tough time sche

Re: [CRYPTO] Switch from JNI to JNA

As we plan to have release sooner, marking release ALPHA tagged make sense IMO. Regards, Uma On 4/25/16, 7:02 PM, "sebb" wrote: >On 26 April 2016 at 02:56, Chen, Haifeng wrote: Sounds like a tough time schedule. It's only one week until May. >> Yeah, it's a tough time schedule. We will ju

RE: [crypto] The standard indentation is 4 spaces per indent

Hi Gary, >> Do you really want this level of Jira tracking? It seems over the top to me. >> Is this process style for this component? In this case I would just do it >> and not Jira it. Then for detailed history, you just look at the commit >> history. Or are you just using Jira as a to-do list

Re: [CRYPTO] Switch from JNI to JNA

On 26 April 2016 at 02:56, Chen, Haifeng wrote: >>> Sounds like a tough time schedule. It's only one week until May. > Yeah, it's a tough time schedule. We will just try moving fast and see what > we can reach at that time. Maybe it's not realistic in one week. It's expensive to change the publi

Re: [CRYPTO] Switch from JNI to JNA

On 26 April 2016 at 02:51, Chen, Haifeng wrote: >>> I am a RERO guy so that is fine with me... BUT... keep in mind that we need >>> to be BC within major releases. Now, me, I do not mind evolving the API >>> right away in a 2.0, but hey that's just me. > In the first release, we would need to th

RE: [CRYPTO] Switch from JNI to JNA

>> Sounds like a tough time schedule. It's only one week until May. Yeah, it's a tough time schedule. We will just try moving fast and see what we can reach at that time. Maybe it's not realistic in one week. -Original Message- From: Benedikt Ritter [mailto:brit...@apache.org] Sent: Tues

RE: [crypto] The standard indentation is 4 spaces per indent

Hi, Do you really want this level of Jira tracking? It seems over the top to me. Is this process style for this component? In this case I would just do it and not Jira it. Then for detailed history, you just look at the commit history. Or are you just using Jira as a to-do list in the early days o

RE: [CRYPTO] Switch from JNI to JNA

>> I am a RERO guy so that is fine with me... BUT... keep in mind that we need >> to be BC within major releases. Now, me, I do not mind evolving the API >> right away in a 2.0, but hey that's just me. In the first release, we would need to think more on API. Would try best to provide a stable

RE: [crypto] The standard indentation is 4 spaces per indent

>>In our coding guidelines [1] we say that "The standard indentation is 4 >>spaces per indent - but respect the number of spaces used by the original." >>The [crypto] Java code I've seen to far is all 2 spaces per indent. >>I think now is the time to do this, most IDEs can do a one-shot format of

Re: [VFS] 2.1 Release Plan

It's from the thread called "Whatever happened to commons-io 2.5?" A few people stepped up to give the necessary permissions and committed his GPG key. On 25 April 2016 at 17:10, Gary Gregory wrote: > Hi, > > Agreed, VFS 2.1 has been too long in the making. We can release ASAP > without fixing m

[crypto] The standard indentation is 4 spaces per indent

Hi all, In our coding guidelines [1] we say that "The standard indentation is 4 spaces per indent - but respect the number of spaces used by the original." The [crypto] Java code I've seen to far is all 2 spaces per indent. I think now is the time to do this, most IDEs can do a one-shot format o

Re: [VFS] 2.1 Release Plan

Hi, Agreed, VFS 2.1 has been too long in the making. We can release ASAP without fixing more bugs IMO. RERO and all. As an Apache committer, your are also an Apache Commons committer, so feel free to create JIRAs, fix bugs and so on. There might be some karma issues with a non-PMC member perform

Re: [CRYPTO] Switch from JNI to JNA

On Sun, Apr 24, 2016 at 11:38 PM, Chen, Haifeng wrote: > >> Maybe its an option to replace JNI by JNA [1]. This would have IHMO > several advantages like > >> * No C code needs to be written, compiled, tested and maintained > >> * Its easier compared to JNI (this could help attracting more people

Re: [io] Make requirement Java 7?

+1 - now is the time. Also I love the java.nio.file APIs. :) On 25 April 2016 at 22:53, Gary Gregory wrote: > Does anyone object updating [io] to Java 7? > > I have a coupe of utils that sit on top of Java 7 IO classes I'd like to > include. > > Gary > > -- > E-Mail: garydgreg...@gmail.com | g

[io] Make requirement Java 7?

Does anyone object updating [io] to Java 7? I have a coupe of utils that sit on top of Java 7 IO classes I'd like to include. Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition JUnit in Action, Second Edi

Fwd: [lang] LANG-1134: New methods for lang3.Validate This closes #87 from github.

This feels to me like it all belongs in [validator]. IMO, we should not fiddle with this class in [lang] and point to [validator]. Gary -- Forwarded message -- From: Date: Sat, Apr 23, 2016 at 6:30 PM Subject: [lang] LANG-1134: New methods for lang3.Validate This closes #87 from g

Fwd: [lang] LANG-1221: add changes.xml entry. This closes #129 from github. Thanks to Pierre Templier

IMO, fixing typos in Javadoc is not worth mentioning as changes.xml entries. Gary -- Forwarded message -- From: Date: Sat, Apr 23, 2016 at 6:11 PM Subject: [lang] LANG-1221: add changes.xml entry. This closes #129 from github. Thanks to Pierre Templier To: comm...@commons.apache.o

[VOTE] Release Validator 1.5.1 based on RC2

Second try: Validator 1.5.1 RC2 is available for review here: https://dist.apache.org/repos/dist/dev/commons/validator/1.5.1_RC2/ (revision 13418) commons-validator-1.5.1-bin.tar.gz.sha1:33a6ffa9b1e9eaa151912312a5ae3df6e996e06f commons-validator-1.5.1-bin.zip.sha1:ffa68a2768c4edea00d16ac1f0481c5

Gary's presence on-line...

... will be on/off until 2016-05-4 due to ISP incompetence (moving house and switching from Frontier to Time Warner). Please be patient if you expect something from me ;-) Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition

[VFS] 2.1 Release Plan

Hi all, There are presently 171 resolved issues sitting in commons-vfs2 2.1-SNAPSHOT, with 4 outstanding (none of which look like blockers to me). The lack of any release of commons-vfs2 in years has been a big problem downstream. This past weekend, I was again annoyed by bugs that have been

[VOTE][ALL] (lazy consensus) Commons Parent 40 based on RC3

Third try: The Apache Commons Parent POM provides common settings for all Apache Commons components. This is a VOTE to release Commons Parent 40 based on RC3 This VOTE by LAZY-CONSENSUS is open for at least 72 hours It will close after April 29 17:00 UTC Changes in this version include: - U

Re: [io] commons-io 2.5 release notes and Javadocs are the 2.4 versions

Benson Margulies schrieb am Mo., 25. Apr. 2016 um 17:42 Uhr: > I followed the instructions for the doc and the javadoc didn't work. I > posted email and no one replied. Now that I am trying turning home I can > research more > Sorry, I must have mist your mail. I've released [lang] several times

Re: [CRYPTO] Switch from JNI to JNA

Chen, Haifeng schrieb am Mo., 25. Apr. 2016 um 08:38 Uhr: > >> Maybe its an option to replace JNI by JNA [1]. This would have IHMO > several advantages like > >> * No C code needs to be written, compiled, tested and maintained > >> * Its easier compared to JNI (this could help attracting more peo

Re: [io] commons-io 2.5 release notes and Javadocs are the 2.4 versions

I followed the instructions for the doc and the javadoc didn't work. I posted email and no one replied. Now that I am trying turning home I can research more On Apr 25, 2016 11:32 AM, "Bertrand Delacretaz" wrote: > Hi, > > The Commons IO 2.5 release notes link at > https://commons.apache.org/prop

[io] commons-io 2.5 release notes and Javadocs are the 2.4 versions

Hi, The Commons IO 2.5 release notes link at https://commons.apache.org/proper/commons-io/ correctly points to https://commons.apache.org/proper/commons-io/upgradeto2_5.html but that says "2.4-SNAPSHOT" and does not match [1]. It looks like the Javadocs aren't updated either, https://commons.apac

Re: [Math] Mismatch: doc/release/release.howto.txt

Done. On 04/25/2016 09:05 AM, Gilles wrote: > On Mon, 25 Apr 2016 08:54:53 -0400, Evan Ward wrote: >> 61c53a4 contains my updates after releasing 3.6.1 > > Could you please make sure that the most up-to-date procedure > is in the "develop" branch? > > Thanks, > Gilles > >> Best Regards, >> Evan >>

Re: [Math] Mismatch: doc/release/release.howto.txt

On Mon, 25 Apr 2016 08:54:53 -0400, Evan Ward wrote: 61c53a4 contains my updates after releasing 3.6.1 Could you please make sure that the most up-to-date procedure is in the "develop" branch? Thanks, Gilles Best Regards, Evan On 04/22/2016 08:30 PM, Gilles wrote: Hi. Contents of doc/re

Re: [Math] Mismatch: doc/release/release.howto.txt

61c53a4 contains my updates after releasing 3.6.1 Best Regards, Evan On 04/22/2016 08:30 PM, Gilles wrote: > Hi. > > Contents of > doc/release/release.howto.txt > is different in branches "develop" and "MATH_3_X". > > Which one is correct? > > Regards, > Gilles > > > ---

[math]: [MATH-1330] - KMeans clustering algorithm, doesn't support clustering of sparse input data.

Hi All, I'd like to provide a solution for [MATH-1330] issue. Before starting I have a concerns regarding the possible design and the actual implementation. Currently all implementations of Clusterer interface expect to receive instance of DistanceMeasure class, which used to compute distance or

Re: [ALL] Dist layout change to per version directories

Le 25/04/2016 11:06, sebb a écrit : > Never suggests it is impossible; however that is not the case. > It hasn't happened yet, but I can imagine that there might be a reason > to maintain two parallel release versions. I agree older branches can keep being maintained, but we'll never bump the maj

Re: [ALL] Dist layout change to per version directories

On 25 April 2016 at 10:13, Stian Soiland-Reyes wrote: > On 21 April 2016 at 12:06, sebb wrote: > >> Note that once we have released (say) NET 3.5, the downloads for NET >> 3.4 need to be removed from the mirrors. >> So the only place that the links will then exist is in the archives. >> >> Unless

Re: [ALL] Dist layout change to per version directories

On Mon, 25 Apr 2016 10:06:12 +0100, sebb wrote: On 25 April 2016 at 09:13, Emmanuel Bourg wrote: Le 25/04/2016 03:04, sebb a écrit : However the distribution naming convention needs to distinguish between releases using different Java packages. I don't think that's a justified requirement,

Re: [ALL] Dist layout change to per version directories

On 21 April 2016 at 12:06, sebb wrote: > Note that once we have released (say) NET 3.5, the downloads for NET > 3.4 need to be removed from the mirrors. > So the only place that the links will then exist is in the archives. > > Unless we also set up links for every past release in every Commons >

Re: [ALL] Dist layout change to per version directories

On 25 April 2016 at 09:13, Emmanuel Bourg wrote: > Le 25/04/2016 03:04, sebb a écrit : > >> However the distribution naming convention needs to distinguish >> between releases using different Java packages. > > I don't think that's a justified requirement, unless we intent to use > the same versio

Re: [ALL] Dist layout change to per version directories

Le 25/04/2016 03:04, sebb a écrit : > However the distribution naming convention needs to distinguish > between releases using different Java packages. I don't think that's a justified requirement, unless we intent to use the same version with different packages (for example a version 3.5 of comm

Build failed in Jenkins: Commons-Compress #99

See Changes: [bodewig] COMPRESS-351 Testcase -- [...truncated 36 lines...] Downloaded: http://repo.maven.apache.org/maven2/org/codehaus/mojo/mojo-parent/33/mojo-parent-33.pom (26 KB at 595.8 KB/

Build failed in Jenkins: Commons-Compress » Apache Commons Compress #99

See Changes: [bodewig] COMPRESS-351 Testcase -- Established TCP socket on 41163 maven3-agent.jar already up to date maven3-interceptor.jar already up to date m

Re: [Math] Re: Trying Fuzzy clustering algorithm in commons apache

On Sun, 24 Apr 2016 23:36:57 +0100, Prakash Poudyal wrote: Well, I need to cluster 1000 sentences into some groups. Since, there are several sentence which could be in any group, therefore, I need to use fuzzy clustering. Lets take 10 sentences tfidf value. Sentence 1 0.50.60.7