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

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

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

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

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

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

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

[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

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

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:

[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

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

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:

[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

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

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

RE: [CRYPTO] Switch from JNI to JNA

>> 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 to >> contribute) >> * Many supported platforms [2],

[GitHub] commons-io pull request: Update FileAlterationMonitor.java

Github user punkmonday closed the pull request at: https://github.com/apache/commons-io/pull/11 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature