[csv] Release planning for commons-csv
Hi, I was wondering if there is currently a specific plan or list of requirements to be fulfilled before the 1.0 of commons-csv is made. For me personally, as well as (I think) other users of commons-csv, it would be very useful to have a release as soon as possible -- even if it is only to streamline the building and releasing of maven-based projects. Apache Phoenix is one such project that is waiting for something that can be deemed a release. If there are open issues that are specifically standing in the way of a release, I would be happy to assist in attempting to resolve them if someone can point me in the right direction. On the other hand, if there are many (technical) issues standing in the way of a 1.0 release, what about making a 0.1 release with the current state of the code? This would satisfy the need of having a released maven artifact for those who need it and are currently making use of snapshot builds. In any case, if there's anything I can do to assist in getting a commons-csv release out the door in the short-term, please let me know. - Gabriel - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [csv] Release planning for commons-csv
As a user cutting my own internal bld +1 On Thursday, May 1, 2014, Gabriel Reid gabriel.r...@gmail.com wrote: Hi, I was wondering if there is currently a specific plan or list of requirements to be fulfilled before the 1.0 of commons-csv is made. For me personally, as well as (I think) other users of commons-csv, it would be very useful to have a release as soon as possible -- even if it is only to streamline the building and releasing of maven-based projects. Apache Phoenix is one such project that is waiting for something that can be deemed a release. If there are open issues that are specifically standing in the way of a release, I would be happy to assist in attempting to resolve them if someone can point me in the right direction. On the other hand, if there are many (technical) issues standing in the way of a 1.0 release, what about making a 0.1 release with the current state of the code? This would satisfy the need of having a released maven artifact for those who need it and are currently making use of snapshot builds. In any case, if there's anything I can do to assist in getting a commons-csv release out the door in the short-term, please let me know. - Gabriel - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org javascript:; For additional commands, e-mail: dev-h...@commons.apache.orgjavascript:;
Re: [csv] Release planning for commons-csv
Hello Gabriel, thanks for you interest in commons-csv. Please see my comments inline. 2014-05-02 8:15 GMT+02:00 Gabriel Reid gabriel.r...@gmail.com: Hi, I was wondering if there is currently a specific plan or list of requirements to be fulfilled before the 1.0 of commons-csv is made. For me personally, as well as (I think) other users of commons-csv, it would be very useful to have a release as soon as possible -- even if it is only to streamline the building and releasing of maven-based projects. Apache Phoenix is one such project that is waiting for something that can be deemed a release. If there are open issues that are specifically standing in the way of a release, I would be happy to assist in attempting to resolve them if someone can point me in the right direction. we are close to a release for a long time now. However we are still looking for a solution to CSV-35 [1] and CSV-58 [2]. There have been long discussions around this issues and to me it looks like there still is no solution. If you have a smart idea feel free to create a patch. On the other hand, if there are many (technical) issues standing in the way of a 1.0 release, what about making a 0.1 release with the current state of the code? This would satisfy the need of having a released maven artifact for those who need it and are currently making use of snapshot builds. At commons we are crazy about binary compatibility ;-) We're going through a lot a trouble to make sure you won't run into jar hell when using our components. This is why you can use commons lang 2.6 alongside commons lang 3.3.2 in the same class path. To achieve this, we change the maven coordinates as well as the package coordinates when we break binary compatibility. The problem with the kind of pre releases you're taking about is, that we would have to go through all this trouble if we encounter a problem with the pre released version that can not be fixed in a binary compatible way. So we would have: maven: org.apache.commons:commons-csv:0.1 package: org.apache.commons.csv Now fixing the issues identified in 1.0 would lead to: maven: org.apache.commons:commons-csv1:1.0 package: org.apache.commons.csv1 Or do we go directly to 2.0? The problem is, even if we declare this release as an alpha release or what ever, people will start using it. And all of a sudden you have commons-csv 0.1 in your class path through transitive dependencies but you really need 1.0 which isn't compatible. You're app has been broken by a rushed out release with an unstable API... In any case, if there's anything I can do to assist in getting a commons-csv release out the door in the short-term, please let me know. The only thing to get this out of the door is to find a solution to CSV-35 and CSV-58. Regards, Benedikt [1] https://issues.apache.org/jira/browse/CSV-35 [2] https://issues.apache.org/jira/browse/CSV-58 - Gabriel - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Re: Apache Commons ApacheCon Europe 2014 ...
2014-04-30 21:24 GMT+02:00 Siegfried Goeschl siegfried.goes...@it20one.com : Hi folks, I collected the responses/feedback so far sorted according to the given committment Commons SCXML - Ate Douma - will present Commons Email - Siegfried Goeschl - will present Commons Math - Thomas Neidhart - likely to present (depending on personal plans) Commons Collections - Thomas Neidhart - likely to present (depending on personal plans) Commons JCS - Thomas Vandahl - would like to present depending on the JCS 2.0 release Commons VFS - Schalk W. Cronjé - would like to present Commons Compress - Stefan Bodewig - might be interested Commons Exec - Siegfried Goeschl - can give a presentation if feasible Commons CLI - Siegfried Goeschl - can give a presentation if feasible but I’m only a user So far * IMHO the Apache Commons Community should be able to present 5-6 components which would fill 3 regular slots * I would really appreciate if more developers would volunteer for a component - it is a great experience to present at a conference :-) I'm interested to present something. Since I work mostly on commons-lang that would be the component I could talk about. Problem is, I don't really know what kind of talk people a interested in. commons-lang has been around for a long time know and there isn't really something special about it. I'm wondering if it is possible to use a slot for a discussion or something. Let people tell us, what they like about lang and what they don't like. This could lead to some ideas for the design of 4.0 which I'm planning to start latter this year. Benedikt Cheers, Siegfried Goeschl On 28 Apr 2014, at 22:59, Thomas Neidhart thomas.neidh...@gmail.com wrote: On 04/17/2014 04:02 PM, Siegfried Goeschl wrote: Hi folks, thanks to Phil and Ate to present Apache Commons at the ApacheCon in Denver :-) I would like to follow up the idea of having a dedicated Apache Commons slots for ApacheCon Europe as we have done it in Atlanta * give the Apache Commons committers the chance to present at ApacheCon while NOT working in BigData, Hadoop or NoSQL * use a regular 45 minutes slot to present two Apache Commons components assuming that many components are rather small * present a couple of Apache Commons component within a dedicated block of slots (conference within the conference) * I chatted with Ate Douma about it and he in turn chatted with other guys so I think this idea is in general appreciated So the questions are * Is this idea appreciated? * Who would volunteer for presenting his/her Apache Commons component? I would be interested to go there and give a talk about some components I am contributing to, like math and collections. Can not give a guarantee yet, as I might be occupied for personal reasons in November. 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 -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Re: [VOTE] Release Math 3.3 based on RC2
Le 01/05/2014 18:15, Thomas Neidhart a écrit : Hi all, I would like to call a vote to release Commons Math 3.3 based on RC2. Changes since RC1: * completed changelog * fixed MATH-1110 * added exclusion filter for findbugs false-positive * disabled 2 tests that failed with Java 8 * javadoc fixes for Java 8 (incomplete, see below) Note: Commons Math 3.3 does compile with Java 8, but creating the site will not work due to some incompatibilities: * javadoc: known doclint issue * findbugs: not ready for java 8 Math 3.3 RC2 is available for review here: https://dist.apache.org/repos/dist/dev/commons/math/ (svn revision 5215) Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1026/org/apache/commons/commons-math3/3.3/ Details of changes since 3.2 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/math/RELEASE-NOTES.txt http://people.apache.org/builds/commons/math/3.3/RC2/changes-report.html The tag is here: https://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_3_3_RC2 (svn revision 1591699) Site: http://people.apache.org/builds/commons/math/3.3/RC2/ (note the apidocs for the 3.3 release will be added with the release) Clirr Report (compared to 3.2): http://people.apache.org/builds/commons/math/3.3/RC2/clirr-report.html (note that there are 4 false positives where the signature of a method has changed such that the parameter type is now the superclass of the previous type) RAT Report: http://people.apache.org/builds/commons/math/3.3/RC2/rat-report.html Findbugs Report: http://people.apache.org/builds/commons/math/3.3/RC2/findbugs.html KEYS: http://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. after 1800 GMT 04-May 2014. [X] +1 Release these artifacts Good. Thanks Thomas! Luc [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Best regards, 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: svn commit: r1591602 - in /commons/proper/collections/trunk/src: changes/ main/java/org/apache/commons/collections4/
-1 I agree with sebb. There is no use case for this. I've elaborated this some more in the jira. 2014-05-01 20:18 GMT+02:00 Dipanjan Laha dipanja...@gmail.com: -1 Imho this usecase also gives a false impression of over riding, so maybe we should make the util classes final as Gary suggested. And imo switching to Guava would be much more of an effort than to compose ones own util class :) On Thursday, 1 May 2014, Jörg Schaible joerg.schai...@gmx.dejavascript:_e(%7B%7D,'cvml','joerg.schai...@gmx.de '); wrote: sebb wrote: On 1 May 2014 14:21, Thomas Neidhart thomas.neidh...@gmail.com wrote: On 05/01/2014 03:03 PM, sebb wrote: On 1 May 2014 12:05, t...@apache.org wrote: Author: tn Date: Thu May 1 11:04:59 2014 New Revision: 1591602 URL: http://svn.apache.org/r1591602 Log: [COLLECTIONS-519] Constructors of *Utils classes are now protected to [allow sub-classing. Thanks to Radoslav Paskalev, Daniel Feist. -1 I don't think this is a good idea. See my comments on the JIRA issue. I consider this to be a compromise considering the fact that previously the util classes all had a public constructor. So when people are migrating from 3.2.1 to 4.0, they have some troubles. To ease the migration I thought that making it protected is safe: * it can not be instantiated Surely it is now instantiable via a sub-class? * if somebody wants to sub-class: at your own risk, like before The composition approach is the right way to go, and I would personally never do something like the issue originator. The problem we have is that if 4.1 now allows sub-classing, how can we ever drop it? We need to grab the opportunity of 4.x to fix all these bad coding practises. Conversion to 4.x will amyway require some effort on the part of users. Let's not spoil the API for all for the sake of a few. +1 We broke the API on purpose. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Re: [jcs] building with JSR-107 TCK
He he, sure :) Here is the error even in Java 7. ERROR] /Users/jlmonteiro/devs/asf/commons/proper/jcs/trunk/commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/JCSCache.java:[92,129] cannot find symbol symbol: class MyThreadFactory location: class org.apache.commons.jcs.utils.threadpool.ThreadPoolManager [ERROR] /Users/jlmonteiro/devs/asf/commons/proper/jcs/trunk/commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/JCSCache.java:[93,68] cannot find symbol symbol: class MyThreadFactory location: class org.apache.commons.jcs.utils.threadpool.ThreadPoolManager JLouis 2014-05-02 7:07 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com: Hey JL, nice to know better to have details ;). When I checked yesterday Mark didnt commit his work and the missing parts of my patch which should be merged so I guess it will be fixed soon. Le 1 mai 2014 23:18, Jean-Louis MONTEIRO jeano...@gmail.com a écrit : I have a compilation issue FYI, either with jdk6 or jdk7 JLouis 2014-05-01 18:43 GMT+02:00 Mark Struberg strub...@yahoo.de: Hi! I've looked at Continuum and it seems like it fails since weeks now. Anyone successfully did run it with jdk-1.6? If so, we should rather look at the Continuum config. LieGrue, strub On Thursday, 1 May 2014, 16:39, Thomas Vandahl t...@apache.org wrote: On 01.05.14 09:52, Mark Struberg wrote: Hi folks! I've moved the TCK run into an own profile. You can activate it via $ mvn clean install -PjcacheTck We should also activate it by default during a release. Btw, why is this project target 1.7? We do not use anything from java7 right? For some reason, The Test(TM) is failing again on Continuum. Is it possible that this has something to do with you latest modifications? One more question regarding the Continuum build. Obviously, the build deploys a snapshot into the snapshot repository. If you look at http://repository.apache.org/content/groups/snapshots/org/apache/commons/commons-jcs/2.0-SNAPSHOT/ almost everything is there, just the jar is missing. Any idea why this happens? 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 -- Jean-Louis -- Jean-Louis
Re: [LANG] Algorithm for fuzzy string matching
Since nobody had objections against adding this, I'll apply this patch. Benedikt 2014-04-28 17:47 GMT+02:00 Benedikt Ritter brit...@apache.org: Hi all, we have a nice PR for StringUtils at github: https://github.com/apache/commons-lang/pull/20 It adds a new string matching algorithm to StringUtils, that calculates a score for the similarity between to strings. This kind of fuzzy matching is known from editors like Sublime Text, Text Mate or Atom. I think this is a very useful features, but as the contributor points out, the is no scientific paper or thesis that provides a reference for the implementation. So this is not _the one_ implementation of a fuzzy string matching score, like our implementations of the Levenshtein or Jaro-Winkler algorithms. So before adding this, I'd like to hear how others feel about this feature. Regards, Benedikt -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Re: [jcs] building with JSR-107 TCK
ok right, In my patch I put it public since a daemon thread factory is quite eusable and important for framewokr. It was not the case Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-05-02 10:13 GMT+02:00 Jean-Louis MONTEIRO jeano...@gmail.com: He he, sure :) Here is the error even in Java 7. ERROR] /Users/jlmonteiro/devs/asf/commons/proper/jcs/trunk/commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/JCSCache.java:[92,129] cannot find symbol symbol: class MyThreadFactory location: class org.apache.commons.jcs.utils.threadpool.ThreadPoolManager [ERROR] /Users/jlmonteiro/devs/asf/commons/proper/jcs/trunk/commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/JCSCache.java:[93,68] cannot find symbol symbol: class MyThreadFactory location: class org.apache.commons.jcs.utils.threadpool.ThreadPoolManager JLouis 2014-05-02 7:07 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com: Hey JL, nice to know better to have details ;). When I checked yesterday Mark didnt commit his work and the missing parts of my patch which should be merged so I guess it will be fixed soon. Le 1 mai 2014 23:18, Jean-Louis MONTEIRO jeano...@gmail.com a écrit : I have a compilation issue FYI, either with jdk6 or jdk7 JLouis 2014-05-01 18:43 GMT+02:00 Mark Struberg strub...@yahoo.de: Hi! I've looked at Continuum and it seems like it fails since weeks now. Anyone successfully did run it with jdk-1.6? If so, we should rather look at the Continuum config. LieGrue, strub On Thursday, 1 May 2014, 16:39, Thomas Vandahl t...@apache.org wrote: On 01.05.14 09:52, Mark Struberg wrote: Hi folks! I've moved the TCK run into an own profile. You can activate it via $ mvn clean install -PjcacheTck We should also activate it by default during a release. Btw, why is this project target 1.7? We do not use anything from java7 right? For some reason, The Test(TM) is failing again on Continuum. Is it possible that this has something to do with you latest modifications? One more question regarding the Continuum build. Obviously, the build deploys a snapshot into the snapshot repository. If you look at http://repository.apache.org/content/groups/snapshots/org/apache/commons/commons-jcs/2.0-SNAPSHOT/ almost everything is there, just the jar is missing. Any idea why this happens? 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 -- Jean-Louis -- Jean-Louis - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Suppressing Javadoc errors with Java 8 - temporary hack
Hi! It turned out that it is always just a bit more complicated. Romain detected that building OpenWebBeans with Java8 did lead to bytecode which does not work on ANY older JVM. The reason is that methods of ConcurrentHashMap (and possibly other) has been moved to an Interface. See OWB-952 [1] for more info. This is ok and a known aspect from a general JVM perspective [2] but needs some caution on our side. Which also means that any TCK, unit tests whatever are NOT sufficient to prove backward compat with older platforms nor that it works on newer platforms. My personal summary is that if we like to support java6 in commons-jcs, then we should really run the release with a jdk-1.6. LieGrue, strub [1] https://issues.apache.org/jira/browse/OWB-952 [2] https://blogs.oracle.com/darcy/entry/how_to_cross_compile_for On Thursday, 1 May 2014, 18:27, Bernd Eckenfels e...@zusammenkunft.net wrote: Am Thu, 1 May 2014 11:01:32 -0500 schrieb Paul Benedict pbened...@apache.org: Wrong syntax is different than missing syntax. The former affects readability while the other just affects usability. Glad you found a way to catch the former but ignore the latter. I agree with the missing should be warning, but I don't see a need to change the configuration. I just fixes the self-closed errors in VFS2 with javadoc8 and it now builds with no errors. It soes show missing @param @return and @throws but they are all warnings. It is using commons-vfs2-project:2.1-SNAPSHOT which is using commons-parent:32 and none of those define Javadoc lint options (only quiet=true). So I am not sure why you need to change the parents? I do see a problem with additional @todo tags. They are configured in the project parent, but it seems from the effective pom that they are not used in all invocations, at least they made the build fail (and I wrongly corrected them). Bernd On Thu, May 1, 2014 at 5:22 AM, Mark Struberg strub...@yahoo.de wrote: Actually the ',' causes a bug in the maven-javadoc-plugin. What seems to work is to split it into 2 parts: additionalparam-Xdoclint:all -Xdoclint:-missing/additionalparam Already started a discussion about adding it to apache-parent over in maven-dev. LieGrue, strub On Thursday, 1 May 2014, 11:05, Mark Struberg strub...@yahoo.de wrote: I would prefer it if the reports were warnings rather than errors, but generally they seem sensible. Allow me to disagree. Breaking the javadoc just because a @param is missing is imo plain wrong. Usually parameters should be self-explaining. I personally only document interfaces and methods where it is *not* clear what the params intend. Please don't let us end up with tons of unnecessary (because obvious) Javadocs just to make java8 happy. I've done some research and asked some Java8 devs I know. Seems additionalparam-Xdoclint:all,-missing/additionalparam could do the trick. Still need to test it though. We should btw add this to the apache-parent pom and not only to commons-parent. LieGrue, strub On Wednesday, 16 April 2014, 20:51, sebb seb...@gmail.com wrote: On 16 April 2014 19:32, Gary Gregory garydgreg...@gmail.com wrote: I personally like the default Java 8 behavior and I would not want to disable it. I would prefer it if the reports were warnings rather than errors, but generally they seem sensible. -1 to adding it to the parent POM as a default. It might have been OK to do so if it were possible to activate it only when Java 8 is being used to a component that targets Java 5,6,7. But suppressing DocLint for source that targets Java 8 seems a very bad idea. Unfortunately ANDed activation conditions for profiles are borked and have been for ages. I think it's OK to use in component POMs because each component will be different. And it can be easily removed when the source has been updated. Gary On Wed, Apr 16, 2014 at 1:06 PM, Matt Benson gudnabr...@gmail.com wrote: I think the implication was that adding it to the parent POM would not encourage us to actually *solve* the underlying issue. ;) Matt On Wed, Apr 16, 2014 at 12:02 PM, Emmanuel Bourg ebo...@apache.org wrote: Le 16/04/2014 18:41, sebb AT ASF a écrit : See below for one way to automatically suppress Javadoc errors when running under Java 8 It should not be adopted as a permanent measure, but may be useful whilst Javadoc is being fixed. Can we add that to the parent pom? Emmanuel Bourg
Re: Apache Commons ApacheCon Europe 2014 ...
Hi Benedikt, there might be a lot of different kinds there :-) IMHO the problem with Let people tell us, what they like about lang and what they don't like is that your presentation depends on the input of the attendees and the presentation setup (good for a small room but bad if you have a large room). One option could for the presentation could be picking common problems and how they are solved with commons-lang * Variable expansion using StrSubstitutor * Dumping third-party objects using ReflectionToStringBuilder * StopWatch for mirco-benchmarks Cheers, Siegfried Goeschl On 02.05.14 09:46, Benedikt Ritter wrote: 2014-04-30 21:24 GMT+02:00 Siegfried Goeschl siegfried.goes...@it20one.com : Hi folks, I collected the responses/feedback so far sorted according to the given committment Commons SCXML - Ate Douma - will present Commons Email - Siegfried Goeschl - will present Commons Math - Thomas Neidhart - likely to present (depending on personal plans) Commons Collections - Thomas Neidhart - likely to present (depending on personal plans) Commons JCS - Thomas Vandahl - would like to present depending on the JCS 2.0 release Commons VFS - Schalk W. Cronjé - would like to present Commons Compress - Stefan Bodewig - might be interested Commons Exec - Siegfried Goeschl - can give a presentation if feasible Commons CLI - Siegfried Goeschl - can give a presentation if feasible but I’m only a user So far * IMHO the Apache Commons Community should be able to present 5-6 components which would fill 3 regular slots * I would really appreciate if more developers would volunteer for a component - it is a great experience to present at a conference :-) I'm interested to present something. Since I work mostly on commons-lang that would be the component I could talk about. Problem is, I don't really know what kind of talk people a interested in. commons-lang has been around for a long time know and there isn't really something special about it. I'm wondering if it is possible to use a slot for a discussion or something. Let people tell us, what they like about lang and what they don't like. This could lead to some ideas for the design of 4.0 which I'm planning to start latter this year. Benedikt Cheers, Siegfried Goeschl On 28 Apr 2014, at 22:59, Thomas Neidhart thomas.neidh...@gmail.com wrote: On 04/17/2014 04:02 PM, Siegfried Goeschl wrote: Hi folks, thanks to Phil and Ate to present Apache Commons at the ApacheCon in Denver :-) I would like to follow up the idea of having a dedicated Apache Commons slots for ApacheCon Europe as we have done it in Atlanta * give the Apache Commons committers the chance to present at ApacheCon while NOT working in BigData, Hadoop or NoSQL * use a regular 45 minutes slot to present two Apache Commons components assuming that many components are rather small * present a couple of Apache Commons component within a dedicated block of slots (conference within the conference) * I chatted with Ate Douma about it and he in turn chatted with other guys so I think this idea is in general appreciated So the questions are * Is this idea appreciated? * Who would volunteer for presenting his/her Apache Commons component? I would be interested to go there and give a talk about some components I am contributing to, like math and collections. Can not give a guarantee yet, as I might be occupied for personal reasons in November. 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Apache Commons ApacheCon Europe 2014 ...
what about commons lightning talks? 5 minutes about a certain commons feature. There are plenty to choose from... LieGrue, strub On Friday, 2 May 2014, 10:28, Siegfried Goeschl sgoes...@gmx.at wrote: Hi Benedikt, there might be a lot of different kinds there :-) IMHO the problem with Let people tell us, what they like about lang and what they don't like is that your presentation depends on the input of the attendees and the presentation setup (good for a small room but bad if you have a large room). One option could for the presentation could be picking common problems and how they are solved with commons-lang * Variable expansion using StrSubstitutor * Dumping third-party objects using ReflectionToStringBuilder * StopWatch for mirco-benchmarks Cheers, Siegfried Goeschl On 02.05.14 09:46, Benedikt Ritter wrote: 2014-04-30 21:24 GMT+02:00 Siegfried Goeschl siegfried.goes...@it20one.com : Hi folks, I collected the responses/feedback so far sorted according to the given committment Commons SCXML - Ate Douma - will present Commons Email - Siegfried Goeschl - will present Commons Math - Thomas Neidhart - likely to present (depending on personal plans) Commons Collections - Thomas Neidhart - likely to present (depending on personal plans) Commons JCS - Thomas Vandahl - would like to present depending on the JCS 2.0 release Commons VFS - Schalk W. Cronjé - would like to present Commons Compress - Stefan Bodewig - might be interested Commons Exec - Siegfried Goeschl - can give a presentation if feasible Commons CLI - Siegfried Goeschl - can give a presentation if feasible but I’m only a user So far * IMHO the Apache Commons Community should be able to present 5-6 components which would fill 3 regular slots * I would really appreciate if more developers would volunteer for a component - it is a great experience to present at a conference :-) I'm interested to present something. Since I work mostly on commons-lang that would be the component I could talk about. Problem is, I don't really know what kind of talk people a interested in. commons-lang has been around for a long time know and there isn't really something special about it. I'm wondering if it is possible to use a slot for a discussion or something. Let people tell us, what they like about lang and what they don't like. This could lead to some ideas for the design of 4.0 which I'm planning to start latter this year. Benedikt Cheers, Siegfried Goeschl On 28 Apr 2014, at 22:59, Thomas Neidhart thomas.neidh...@gmail.com wrote: On 04/17/2014 04:02 PM, Siegfried Goeschl wrote: Hi folks, thanks to Phil and Ate to present Apache Commons at the ApacheCon in Denver :-) I would like to follow up the idea of having a dedicated Apache Commons slots for ApacheCon Europe as we have done it in Atlanta * give the Apache Commons committers the chance to present at ApacheCon while NOT working in BigData, Hadoop or NoSQL * use a regular 45 minutes slot to present two Apache Commons components assuming that many components are rather small * present a couple of Apache Commons component within a dedicated block of slots (conference within the conference) * I chatted with Ate Douma about it and he in turn chatted with other guys so I think this idea is in general appreciated So the questions are * Is this idea appreciated? * Who would volunteer for presenting his/her Apache Commons component? I would be interested to go there and give a talk about some components I am contributing to, like math and collections. Can not give a guarantee yet, as I might be occupied for personal reasons in November. 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Javadoc with Java 8 (Was: svn commit: r1591664 [2/2] - ...)
On 5/1/14, 7:20 PM, Paul Benedict wrote:
Phil, I don't know who was telling people Javadoc is XML. I never heard of
that.
Well, could be just be personal ignorance, but the practice of
closing tags in commons javadoc goes back to at least 2002. You can
see it in the [lang] Developer Guide (closing p/'s are referenced
there) and throughout Commons components. I could not find much in
the archives actually discussing it. I vaguely recall some argument
that valid XML would be easier to process with tools other than the
javadoc tool itself. Personally, I find it a little more readable.
I honestly don't care, but do find it irritating that we are being
forced to fiddle with this stuff to keep the tool happy / producing
good warnings.
I agree with Gilles though that entities damage readability and
using *more* of them is a step in the wrong direction. I will -1
commits that rip out MathJax or mangle the embedded TeX (unless and
until someone explains for legitimate reasons why MathJax itself is
a bad idea).
Phil
AFAIK, it has always been HTML but the Javadoc parser didn't care to
enforce it. Now it's enforcing it so the only good Javadoc is HTML as it
always was. If anyone wants to show me Sun saying Javadoc was XML, I'll
gladly eat my words and enjoy learning something new. But why fight the
technology? Javadoc isn't ever going to be XML so why continue going down
that path?
On Thu, May 1, 2014 at 9:15 PM, Phil Steitz phil.ste...@gmail.com wrote:
On 5/1/14, 2:31 PM, Paul Benedict wrote:
Gilles,
Javadoc is not XHTML but HTML... and not just HTML, but an HTML fragment.
Documentation writers need to remember that their content is being placed
within a bigger document so correct tag usage is important to get
predictable results.
I think all Math committers will find this thread about the Javadoc
changes
for Java 8 to be informative (switching to thread view can help):
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019269.html
Thanks for sharing. Basically, I would say what Stephen said
which is that the J8 ridiculouslness should be roundly ignored.
it is truly comical that roughly 10 years ago, we started
assiduously adding /p's so we would have valid XML. Now the
best minds are telling us that we need to rip all of that out. I
am calling . Lets focus on getting good, complete Javadoc.
Turn off whatever warning crap is being emitted. I agree with
Gilles on this.
Phil
Paul
On Thu, May 1, 2014 at 4:22 PM, Gilles gil...@harfang.homelinux.org
wrote:
On Thu, 01 May 2014 22:49:58 +0200, Thomas Neidhart wrote:
On 05/01/2014 10:31 PM, Gilles wrote:
Hi.
I don't like most of the changes performed on the Javadoc; most of
them
are going in the wrong direction IMHO, the most severe being the use
of
HTML entities rather than using MathJax.[1]
well, this does not really come as a surprise.
But seriously, about which changes are you talking?
There are 5 groups of changes which have been performed so far:
* replace br/ with p tags
Trigerring an error on self-closing (and valid XML) tags seems
utterly stupid. [There might be some deeper reasons which I'm not
aware of at this point, since those nice Java 8 features are
totally new to me.]
* escape angle brackets (, ) with the corresponding HTML entities
Does Java 8 refuse angle brackets enclosed in {@code ...} tags?
* remove unneeded /p tags where java 8 javadoc complained
In XML, closing tags are never unneeded, they are required; so it
looks like Java 8 decided to be XML non-compliant.
If this is so, my opinion is to not use p anymore!
* add code tags within pre blocks as sub was not allowed
otherwise
* fix wrong/missing closing of tags (mostly ol, ul, code, li)
The only change being potentially controversial wrt readability are the
angle brackets, but there are already many cases where the entities are
used and this is only good practice and making it consistent in the
whole codebase.
I don't agree that reducing legibility is good practise.
Last time I checked W3C was trying to make HTML a valid XML language;
now from what I read in this commit, Java 8 insists on being invalid
XML...
Since when was it decided to comply with Java 8 despite that it does
not
seem to be an obvious move?
Feel free to revert my change, I was only determined to avoid potential
problems with the 3.3 vote as some people build with Java 8 and report
errors with it.
As the build with Java 8 is broken anyway (due to findbugs), it was a
wasted effort for now, thus I stopped in the middle of it.
Until there is agreement on a way out, I think that we should have
followed the route proposed here:
http://blog.joda.org/2014/02/turning-off-doclint-in-jdk-8-javadoc.html
(i.e. disable the enforcement of the new rules).
Well, I tried that, but the setting did not seem to work with java 7,
thus I had to remove it again.
Then, as I indicated in the [vote]
Re: [csv] Release planning for commons-csv
Hi Benedikt, Thanks for the feedback. My comments are inlined below. On Fri, May 2, 2014 at 9:41 AM, Benedikt Ritter brit...@apache.org wrote: 2014-05-02 8:15 GMT+02:00 Gabriel Reid gabriel.r...@gmail.com: If there are open issues that are specifically standing in the way of a release, I would be happy to assist in attempting to resolve them if someone can point me in the right direction. we are close to a release for a long time now. However we are still looking for a solution to CSV-35 [1] and CSV-58 [2]. There have been long discussions around this issues and to me it looks like there still is no solution. If you have a smart idea feel free to create a patch. Thanks for pointing these out. I'll certainly take a look at them in greater detail to see if there's anything I can see or think of. At commons we are crazy about binary compatibility ;-) We're going through a lot a trouble to make sure you won't run into jar hell when using our components. This is why you can use commons lang 2.6 alongside commons lang 3.3.2 in the same class path. To achieve this, we change the maven coordinates as well as the package coordinates when we break binary compatibility. [snip] The problem is, even if we declare this release as an alpha release or what ever, people will start using it. And all of a sudden you have commons-csv 0.1 in your class path through transitive dependencies but you really need 1.0 which isn't compatible. You're app has been broken by a rushed out release with an unstable API... Understood, and I certainly think that worry about binary compatibility is a worthy cause (and certainly don't want to try to convince the project to go against that principle). However, I think that there are some additional things to consider here as well. Both of the blocking issues are over two years old, with very little activity in the past 6 months. There are currently people making use of commons-csv by doing things like copying the code into their own repo, or making their own release build. These are the same users who are intended to be protected by the promise of binary compatibility, but they (and projects that make use of their published artifacts) will suffer from the same consequences that you outlined by breaking binary incompatibility. The argument could of course be made that people shouldn't be doing things like making their own build or folding the commons-csv code into their own projects, but the fact is that people are doing this (just like people will use a 0.1 release, despite any kinds of warnings about possible future incompatibilites). Additionally, the two issues in question are both classified as bugs, and it appears that both will (or at least could be) eventually be resolved by adding additional configuration methods. This addition of additional configuration methods won't break backwards compatibility. Basically my points are: * by delaying a release to protect users, the same users are doing things which bring the same (or even worse) risks that the delayed release is supposed to be protecting them from * it appears to be possible to resolve the two blocking issues in the future without breaking binary compatibility - Gabriel - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1591602 - in /commons/proper/collections/trunk/src: changes/ main/java/org/apache/commons/collections4/
Reverted commit in r1591832.
On Thu, May 1, 2014 at 3:03 PM, sebb seb...@gmail.com wrote:
On 1 May 2014 12:05, t...@apache.org wrote:
Author: tn
Date: Thu May 1 11:04:59 2014
New Revision: 1591602
URL: http://svn.apache.org/r1591602
Log:
[COLLECTIONS-519] Constructors of *Utils classes are now protected to
allow sub-classing. Thanks to Radoslav Paskalev, Daniel Feist.
-1
I don't think this is a good idea.
See my comments on the JIRA issue.
Modified:
commons/proper/collections/trunk/src/changes/changes.xml
commons/proper/collections/trunk/src/main/java/org/apache/commons/collections4/ClosureUtils.java
commons/proper/collections/trunk/src/main/java/org/apache/commons/collections4/CollectionUtils.java
commons/proper/collections/trunk/src/main/java/org/apache/commons/collections4/ComparatorUtils.java
commons/proper/collections/trunk/src/main/java/org/apache/commons/collections4/EnumerationUtils.java
commons/proper/collections/trunk/src/main/java/org/apache/commons/collections4/FactoryUtils.java
commons/proper/collections/trunk/src/main/java/org/apache/commons/collections4/IteratorUtils.java
commons/proper/collections/trunk/src/main/java/org/apache/commons/collections4/ListUtils.java
commons/proper/collections/trunk/src/main/java/org/apache/commons/collections4/MapUtils.java
commons/proper/collections/trunk/src/main/java/org/apache/commons/collections4/MultiMapUtils.java
commons/proper/collections/trunk/src/main/java/org/apache/commons/collections4/PredicateUtils.java
commons/proper/collections/trunk/src/main/java/org/apache/commons/collections4/QueueUtils.java
commons/proper/collections/trunk/src/main/java/org/apache/commons/collections4/SetUtils.java
commons/proper/collections/trunk/src/main/java/org/apache/commons/collections4/SplitMapUtils.java
commons/proper/collections/trunk/src/main/java/org/apache/commons/collections4/TransformerUtils.java
commons/proper/collections/trunk/src/main/java/org/apache/commons/collections4/TrieUtils.java
Modified: commons/proper/collections/trunk/src/changes/changes.xml
URL:
http://svn.apache.org/viewvc/commons/proper/collections/trunk/src/changes/changes.xml?rev=1591602r1=1591601r2=1591602view=diff
==
--- commons/proper/collections/trunk/src/changes/changes.xml (original)
+++ commons/proper/collections/trunk/src/changes/changes.xml Thu May 1
11:04:59 2014
@@ -22,6 +22,9 @@
body
release version=4.1 date=TBD description=
+action issue=COLLECTIONS-519 dev=tn type=fix
due-to=Radoslav Paskalev, Daniel Feist
+ Constructors of *Utils classes are now protected to allow
sub-classing.
+/action
action issue=COLLECTIONS-512 dev=tn type=fix due-to=Cyrille
Artho
TransformingComparator did not comply with the contract of
Object#equals.
/action
Modified:
commons/proper/collections/trunk/src/main/java/org/apache/commons/collections4/ClosureUtils.java
URL:
http://svn.apache.org/viewvc/commons/proper/collections/trunk/src/main/java/org/apache/commons/collections4/ClosureUtils.java?rev=1591602r1=1591601r2=1591602view=diff
==
---
commons/proper/collections/trunk/src/main/java/org/apache/commons/collections4/ClosureUtils.java
(original)
+++
commons/proper/collections/trunk/src/main/java/org/apache/commons/collections4/ClosureUtils.java
Thu May 1 11:04:59 2014
@@ -56,7 +56,7 @@ public class ClosureUtils {
/**
* This class is not normally instantiated.
*/
-private ClosureUtils() {}
+protected ClosureUtils() {}
/**
* Gets a Closure that always throws an exception.
Modified:
commons/proper/collections/trunk/src/main/java/org/apache/commons/collections4/CollectionUtils.java
URL:
http://svn.apache.org/viewvc/commons/proper/collections/trunk/src/main/java/org/apache/commons/collections4/CollectionUtils.java?rev=1591602r1=1591601r2=1591602view=diff
==
---
commons/proper/collections/trunk/src/main/java/org/apache/commons/collections4/CollectionUtils.java
(original)
+++
commons/proper/collections/trunk/src/main/java/org/apache/commons/collections4/CollectionUtils.java
Thu May 1 11:04:59 2014
@@ -185,7 +185,7 @@ public class CollectionUtils {
/**
* codeCollectionUtils/code should not normally be instantiated.
*/
-private CollectionUtils() {}
+protected CollectionUtils() {}
/**
* Returns the immutable EMPTY_COLLECTION with generic type safety.
Modified:
commons/proper/collections/trunk/src/main/java/org/apache/commons/collections4/ComparatorUtils.java
URL:
[CANCEL][VOTE] Release Math 3.3 based on RC2
The vote is cancelled. The changes to javadoc have been reverted in r1591835. Unfortunately, I will not be able to cut another RC, thus I step down as RM. Best regards, Thomas On Thu, May 1, 2014 at 6:15 PM, Thomas Neidhart thomas.neidh...@gmail.comwrote: Hi all, I would like to call a vote to release Commons Math 3.3 based on RC2. Changes since RC1: * completed changelog * fixed MATH-1110 * added exclusion filter for findbugs false-positive * disabled 2 tests that failed with Java 8 * javadoc fixes for Java 8 (incomplete, see below) Note: Commons Math 3.3 does compile with Java 8, but creating the site will not work due to some incompatibilities: * javadoc: known doclint issue * findbugs: not ready for java 8 Math 3.3 RC2 is available for review here: https://dist.apache.org/repos/dist/dev/commons/math/ (svn revision 5215) Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1026/org/apache/commons/commons-math3/3.3/ Details of changes since 3.2 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/math/RELEASE-NOTES.txt http://people.apache.org/builds/commons/math/3.3/RC2/changes-report.html The tag is here: https://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_3_3_RC2 (svn revision 1591699) Site: http://people.apache.org/builds/commons/math/3.3/RC2/ (note the apidocs for the 3.3 release will be added with the release) Clirr Report (compared to 3.2): http://people.apache.org/builds/commons/math/3.3/RC2/clirr-report.html (note that there are 4 false positives where the signature of a method has changed such that the parameter type is now the superclass of the previous type) RAT Report: http://people.apache.org/builds/commons/math/3.3/RC2/rat-report.html Findbugs Report: http://people.apache.org/builds/commons/math/3.3/RC2/findbugs.html KEYS: http://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. after 1800 GMT 04-May 2014. [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Best regards, Thomas
Re: Apache Commons ApacheCon Europe 2014 ...
I have another suggestion for a Commons talk. If many Apache committers attend the talk I think it might be interesting to explain/remind how Commons is a central playground to share common code between various Apache projets. I guess many devs at Apache have forgotten or are unaware of this. I'm pretty sure interesting chunks of code are waiting to be shared but the devs haven't realized it yet. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1591602 - in /commons/proper/collections/trunk/src: changes/ main/java/org/apache/commons/collections4/
Le 01/05/2014 16:13, Thomas Neidhart a écrit : If there is too much trouble upgrading to collections 4, they might also switch to guava, which I have seen a couple of times already. And they'll cry on every Guava update when deprecated methods are aggressively removed ;) Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[SANDBOX][BEANUTILS2] Property expressions
Hi all, one of the goal of BeanUtils2 is to provide the same functionality as BeanUtils1. In BeanUtils1 you can do something like this: BeanUtils.getProperty(person, address.city.zipCode); This would be translated into: person.getAddress().getCity().getZipCode(); The same can be done with mapped and indexed properties: BeanUtils.getProperty(person, contact(5).name); which would be translated to: person.getContact(5).getName(); BeanUtils2 provides a fluent API where the first example would be done via: on(person).get(address).get(city).get(zipCode) and the second: on(person).getIndexed(contact).at(5).get(name) We are currently thinking about how we can implement the property expressions. We are discussing this in SANDBOX-464 [1] and there is already a patch. I'm currently unsure whether we should allow mixing up the fluent API and property expressions. The contributor makes some good examples of what kind of awful code could be created: on(addressBook).get(provider(google).contact[5] ).getMapped(address).with(home).get(street.yetAnotherNestedProperty) on the other hand I don't want to force people into doing stuff like this: String path = ...int pos = ... on(bean).get(path + [ + pos + ]); Currently I'm tempted to allow mixing up both API styles, but I'd like to here your opinion first. Benedikt [1] https://issues.apache.org/jira/browse/SANDBOX-464 -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
[SANDBOX][BEANUTILS2] Changing code style
Hi all, BeanUtils2 uses the maven code style rules. Every now and then I have to reject patches because they don't follow these conventions. I'd like to change the formatting rules to a more standard rule set for the following reasons: - maven style is very verbose, since it uses a lot of spaces and curly braces have to be placed on new lines - a great majority of our components uses the Sun/Eclipse formatting with spaces - Setting up IDEs like IntelliJ or Eclipse is easier with the Sun/Eclipse style, because the only thing you have to change is the tab policy. Using the maven style implies that one has to import the rule set. If no one objects, I'll reformat the source code and update the check style rules. Regards, Benedikt -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
RE: [SANDBOX][BEANUTILS2] Property expressions
There is also our own jxpath. Gary div Original message /divdivFrom: Benedikt Ritter brit...@apache.org /divdivDate:05/02/2014 06:40 (GMT-05:00) /divdivTo: Commons Developers List dev@commons.apache.org /divdivSubject: [SANDBOX][BEANUTILS2] Property expressions /divdiv /divHi all, one of the goal of BeanUtils2 is to provide the same functionality as BeanUtils1. In BeanUtils1 you can do something like this: BeanUtils.getProperty(person, address.city.zipCode); This would be translated into: person.getAddress().getCity().getZipCode(); The same can be done with mapped and indexed properties: BeanUtils.getProperty(person, contact(5).name); which would be translated to: person.getContact(5).getName(); BeanUtils2 provides a fluent API where the first example would be done via: on(person).get(address).get(city).get(zipCode) and the second: on(person).getIndexed(contact).at(5).get(name) We are currently thinking about how we can implement the property expressions. We are discussing this in SANDBOX-464 [1] and there is already a patch. I'm currently unsure whether we should allow mixing up the fluent API and property expressions. The contributor makes some good examples of what kind of awful code could be created: on(addressBook).get(provider(google).contact[5] ).getMapped(address).with(home).get(street.yetAnotherNestedProperty) on the other hand I don't want to force people into doing stuff like this: String path = ...int pos = ... on(bean).get(path + [ + pos + ]); Currently I'm tempted to allow mixing up both API styles, but I'd like to here your opinion first. Benedikt [1] https://issues.apache.org/jira/browse/SANDBOX-464 -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Re: [LANG] Algorithm for fuzzy string matching
Do we really want this in SU or should it live in its own class? Gary div Original message /divdivFrom: Benedikt Ritter brit...@apache.org /divdivDate:05/02/2014 04:15 (GMT-05:00) /divdivTo: Commons Developers List dev@commons.apache.org /divdivSubject: Re: [LANG] Algorithm for fuzzy string matching /divdiv /divSince nobody had objections against adding this, I'll apply this patch. Benedikt 2014-04-28 17:47 GMT+02:00 Benedikt Ritter brit...@apache.org: Hi all, we have a nice PR for StringUtils at github: https://github.com/apache/commons-lang/pull/20 It adds a new string matching algorithm to StringUtils, that calculates a score for the similarity between to strings. This kind of fuzzy matching is known from editors like Sublime Text, Text Mate or Atom. I think this is a very useful features, but as the contributor points out, the is no scientific paper or thesis that provides a reference for the implementation. So this is not _the one_ implementation of a fuzzy string matching score, like our implementations of the Levenshtein or Jaro-Winkler algorithms. So before adding this, I'd like to hear how others feel about this feature. Regards, Benedikt -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Re: [LANG] Algorithm for fuzzy string matching
Hi Gary, we had a discussion about this some time ago, where I proposed to create a new class (let's call it StringMetrics) and move Levenshtein and Jaro Winkler to it. We decided not to do this in 3.x, since SU already has 180+ methods which will have to be split up in the next major release. Benedikt 2014-05-02 13:00 GMT+02:00 Gary Gregory garydgreg...@gmail.com: Do we really want this in SU or should it live in its own class? Gary div Original message /divdivFrom: Benedikt Ritter brit...@apache.org /divdivDate:05/02/2014 04:15 (GMT-05:00) /divdivTo: Commons Developers List dev@commons.apache.org /divdivSubject: Re: [LANG] Algorithm for fuzzy string matching /divdiv /divSince nobody had objections against adding this, I'll apply this patch. Benedikt 2014-04-28 17:47 GMT+02:00 Benedikt Ritter brit...@apache.org: Hi all, we have a nice PR for StringUtils at github: https://github.com/apache/commons-lang/pull/20 It adds a new string matching algorithm to StringUtils, that calculates a score for the similarity between to strings. This kind of fuzzy matching is known from editors like Sublime Text, Text Mate or Atom. I think this is a very useful features, but as the contributor points out, the is no scientific paper or thesis that provides a reference for the implementation. So this is not _the one_ implementation of a fuzzy string matching score, like our implementations of the Levenshtein or Jaro-Winkler algorithms. So before adding this, I'd like to hear how others feel about this feature. Regards, Benedikt -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
[VFS] JDK 8 2.1-SNAPSHOT
Does anyone else have failures building VFS 2.1 with JDK8 (SVN rev 1591869)? I am seeing this test failure building on Mac. --- Test set: org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest --- Tests run: 9, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.012 sec FAILURE! - in org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest testSmallFS(org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest) Time elapsed: 0.007 sec ERROR! java.lang.IllegalArgumentException: Self-suppression not permitted at org.apache.commons.vfs2.provider.ram.RamFileObject.resize(RamFileObject.java:277) at org.apache.commons.vfs2.provider.ram.RamFileOutputStream.write(RamFileOutputStream.java:68) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) at org.apache.commons.vfs2.util.MonitorOutputStream.flush(MonitorOutputStream.java:114) at java.io.FilterOutputStream.close(FilterOutputStream.java:158) at org.apache.commons.vfs2.util.MonitorOutputStream.close(MonitorOutputStream.java:54) at org.apache.commons.vfs2.provider.DefaultFileContent$FileContentOutputStream.close(DefaultFileContent.java:711) at org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest.testSmallFS(CustomRamProviderTest.java:264) -- Schalk W. Cronjé @ysb33r
Re: JDK8 compatible javadoc
-Xdoclint:all -Xdoclint:-missing -Xdoclint:-html That should fix the issue. ATTN: this must ONLY be done in a java8 profile! If you set those params in older java versions (1.7, 1.6) then the build will blow up... LieGrue, strub On Wednesday, 30 April 2014, 7:47, Paul Benedict pbened...@apache.org wrote: Looks like I found the message I alluded to. Make sure you read the whole thread for fun ;-) http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019269.html On Wed, Apr 30, 2014 at 12:36 AM, Thomas Neidhart thomas.neidh...@gmail.com wrote: On 04/30/2014 03:50 AM, Gary Gregory wrote: Well, it does not support HTML in the sense that you MUST close all tags. No lonely ps... Unless something has changed for jdk8, lonely ps are supported and even advertised like this in the main javadoc guide from Sun/Oracle: http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html Also there are components like collections that heavily rely on this. Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Cheers, Paul
Re: [Math] Javadoc with Java 8 (Was: svn commit: r1591664 [2/2] - ...)
On Fri, 02 May 2014 01:48:28 -0700, Phil Steitz wrote:
On 5/1/14, 7:20 PM, Paul Benedict wrote:
Phil, I don't know who was telling people Javadoc is XML. I never
heard of
that.
Well, could be just be personal ignorance, but the practice of
closing tags in commons javadoc goes back to at least 2002. You can
see it in the [lang] Developer Guide (closing p/'s are referenced
there) and throughout Commons components. I could not find much in
the archives actually discussing it. I vaguely recall some argument
that valid XML would be easier to process with tools other than the
javadoc tool itself. Personally, I find it a little more readable.
I honestly don't care, but do find it irritating that we are being
forced to fiddle with this stuff to keep the tool happy / producing
good warnings.
According to
http://docs.oracle.com/javase/8/docs/technotes/guides/javadoc/whatsnew-7.html
the javadoc tool produces HTML 4.01 Transitional (and thus assumes,
but does not check, that the Javadoc fragments are compliant with that
specification).
It seems that Java 8 goes some way to check for SGML compliance while
not enforcing HTML 4.01 Strict: According to the the W3C validator
service, every paragraph (including the first sentence in Javadoc!),
should be preceded by a p.
SGML compliance requires supporting null end tags[1]:
http://www.webdevout.net/tidings/2006/04/16/the-problem-with-the-net/
which makes _all_ self-closing tags invalid, a.o. p/ and br/.
XML being ubiquitous in the programming world (and somewhat beyond),
it was an understandable mistake that its syntax would be picked up
in preference to this obscure feature of (somewhat obsoleted) SGML.
[Who is using NET in Javadoc? Actually, who has ever used NET?]
In HTML5, the situation becomes more consistent[2]:
1. p/ is still invalid, because a paragraph cannot be empty (i.e.
it must logically contain the sentence that make up the
paragraph).[3]
2. br/ is accepted. But it is recommended only in specific
situations[4]:
http://www.w3.org/TR/2011/WD-html5-author-20110705/the-br-element.html#the-br-element
Unless I'm mistaken, the javadoc tool of Java 8 thus forbids a syntax
that will be valid in HTML5 for the sake of supporting a feature that
will disappear in HTML5!
I'd tentatively conclude that we should use the following syntax:
p
Some documentation. Further details.
/p
p
Some more documentation.
/p
That would make the fragment valid as HTML 4.01 and 5, as well as XML.
I agree with Gilles though that entities damage readability and
using *more* of them is a step in the wrong direction.
This is what really started me.
Javadoc in itself is not valid HTML: it must be processed by the
javadoc
tool to _produce_ HTML. Hence there is no advantage in creating a
Javadoc
content that is as close as possible to HTML compliance when more
legible
alternatives exist such as {@code a = 0}.
I will -1
commits that rip out MathJax or mangle the embedded TeX (unless and
until someone explains for legitimate reasons why MathJax itself is
a bad idea).
Do you mean that Javadoc 8 requires that
\( a = 0 \)
be written
\( a le; 0 \)
?
Regards,
Gilles
[1] It looks like the existence of this SGML feature is a remnant from
an epoch where every byte of storage mattered.
And dropping it in XML seemed quite sensible; thus increasing the
consistency and legibility of the notation, and allowing an obvious
shortcut (the self-closing tag) for empty elements.
[2] Do we agree that HTML5 _is_ the future of HTML? Is Javadoc going
to stick with SGML/HTML4.01?
[3] p is routinely, but wrongly, used (in CM's Javadoc) as a
_separator_.
[4] The way I used br in CM's Javadoc would probably fall in the not
recommended category.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: JDK8 compatible javadoc
So the plan is to let each [component] pick how they want to deal with Java 8 right? Gary On Fri, May 2, 2014 at 8:13 AM, Mark Struberg strub...@yahoo.de wrote: -Xdoclint:all -Xdoclint:-missing -Xdoclint:-html That should fix the issue. ATTN: this must ONLY be done in a java8 profile! If you set those params in older java versions (1.7, 1.6) then the build will blow up... LieGrue, strub On Wednesday, 30 April 2014, 7:47, Paul Benedict pbened...@apache.org wrote: Looks like I found the message I alluded to. Make sure you read the whole thread for fun ;-) http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019269.html On Wed, Apr 30, 2014 at 12:36 AM, Thomas Neidhart thomas.neidh...@gmail.com wrote: On 04/30/2014 03:50 AM, Gary Gregory wrote: Well, it does not support HTML in the sense that you MUST close all tags. No lonely ps... Unless something has changed for jdk8, lonely ps are supported and even advertised like this in the main javadoc guide from Sun/Oracle: http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html Also there are components like collections that heavily rely on this. Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Cheers, Paul -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [VFS] release preparation: clirr report
I'm not sure how fine grained control we have or want to get over Clirr. For now, I'd rather know about all the differences. We can document how to interpret the Clirr report on the site and release notes as well. Gary On Thu, May 1, 2014 at 3:23 PM, Bernd Eckenfels e...@zusammenkunft.netwrote: Hello, in preparation of the VFS2.1 release I was reviewing the Clirr report. It has quite a number of errors, especially in regard to new Interface methods. # Method 'public long write(org.apache.commons.vfs2.FileContent)' has been added to an interface # Method 'public boolean isFile()' has been added to an interface # Method 'public int deleteAll()' has been added to an interface I think those are all compatible in normal usage since implementors would expand a abstract base class. Is there a way to cover that in Clirr? Would we keep the errors in the release and describe it in the release notes? There are also some changes to providers. They look less clear but most of them are protected methods. Why does that show up in the clirr report at all? I have a sample site here (not sure if it is correctly released but it is enough to look at the Clirr) http://people.apache.org/~ecki/commons-vfs/commons-vfs2/clirr-report.html Gruss Bernd - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: JDK8 compatible javadoc
Le 02/05/2014 15:37, Gary Gregory a écrit : So the plan is to let each [component] pick how they want to deal with Java 8 right? As a side note, I'd like to emphasize that our source code is being recompiled by downstream packagers, most notably Linux distributions. Fedora 21 will default to Java 8 and Debian is working toward this goal, so it would be nice if our components do compile and work on Java 8. For now math, exec and bcel aren't working properly. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Math 3.3 based on RC2
On Thu, May 1, 2014 at 5:10 PM, Paul Benedict pbened...@apache.org wrote: Personally, I don't see a reason to revert the javadoc changes. There's no turning back the clock on the javadoc processing engine -- it's not like 9 or 10 is going to stop warning about malformed HTML. Although I am not a Math contributor/commiter, I support the change since going forward it will make the doc generation predictable. +1 Gary On Thu, May 1, 2014 at 4:07 PM, Gilles gil...@harfang.homelinux.org wrote: On Thu, 01 May 2014 18:15:39 +0200, Thomas Neidhart wrote: Hi all, I would like to call a vote to release Commons Math 3.3 based on RC2. Changes since RC1: * completed changelog * fixed MATH-1110 * added exclusion filter for findbugs false-positive * disabled 2 tests that failed with Java 8 * javadoc fixes for Java 8 (incomplete, see below) Note: Commons Math 3.3 does compile with Java 8, but creating the site will not work due to some incompatibilities: * javadoc: known doclint issue * findbugs: not ready for java 8 Math 3.3 RC2 is available for review here: https://dist.apache.org/repos/dist/dev/commons/math/ (svn revision 5215) Maven artifacts are here: https://repository.apache.org/content/repositories/ orgapachecommons-1026/org/apache/commons/commons-math3/3.3/ Details of changes since 3.2 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/math/RELEASE-NOTES.txt http://people.apache.org/builds/commons/math/3.3/RC2/ changes-report.html The tag is here: https://svn.apache.org/repos/asf/commons/proper/math/tags/ MATH_3_3_RC2 (svn revision 1591699) Site: http://people.apache.org/builds/commons/math/3.3/RC2/ (note the apidocs for the 3.3 release will be added with the release) Clirr Report (compared to 3.2): http://people.apache.org/builds/commons/math/3.3/RC2/ clirr-report.html (note that there are 4 false positives where the signature of a method has changed such that the parameter type is now the superclass of the previous type) RAT Report: http://people.apache.org/builds/commons/math/3.3/RC2/rat-report.html Findbugs Report: http://people.apache.org/builds/commons/math/3.3/RC2/findbugs.html KEYS: http://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. after 1800 GMT 04-May 2014. [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [X] -1 I oppose this release because... ... some commits were performed solely to support Java 8. Since it did not suffice and the changes are not without drawbacks IMHO, I think that they should be reverted. Thanks for identifying the problem we'll encounter when transitioning to Java 8. I think that a discussion is required to consider the possible workarounds. At this point, we should just advertize that CM is not source-compatible with Java 8, open an issue in order to collect all the related problems, and explore how to best solve them (by asking everyone's opinions). Sorry, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Cheers, Paul -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [Math] Javadoc with Java 8 (Was: svn commit: r1591664 [2/2] - ...)
pThis is a paragraph./p
p/ is useless
Gary
On Thu, May 1, 2014 at 10:20 PM, Paul Benedict pbened...@apache.org wrote:
Phil, I don't know who was telling people Javadoc is XML. I never heard of
that. AFAIK, it has always been HTML but the Javadoc parser didn't care to
enforce it. Now it's enforcing it so the only good Javadoc is HTML as it
always was. If anyone wants to show me Sun saying Javadoc was XML, I'll
gladly eat my words and enjoy learning something new. But why fight the
technology? Javadoc isn't ever going to be XML so why continue going down
that path?
On Thu, May 1, 2014 at 9:15 PM, Phil Steitz phil.ste...@gmail.com wrote:
On 5/1/14, 2:31 PM, Paul Benedict wrote:
Gilles,
Javadoc is not XHTML but HTML... and not just HTML, but an HTML
fragment.
Documentation writers need to remember that their content is being
placed
within a bigger document so correct tag usage is important to get
predictable results.
I think all Math committers will find this thread about the Javadoc
changes
for Java 8 to be informative (switching to thread view can help):
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019269.html
Thanks for sharing. Basically, I would say what Stephen said
which is that the J8 ridiculouslness should be roundly ignored.
it is truly comical that roughly 10 years ago, we started
assiduously adding /p's so we would have valid XML. Now the
best minds are telling us that we need to rip all of that out. I
am calling . Lets focus on getting good, complete Javadoc.
Turn off whatever warning crap is being emitted. I agree with
Gilles on this.
Phil
Paul
On Thu, May 1, 2014 at 4:22 PM, Gilles gil...@harfang.homelinux.org
wrote:
On Thu, 01 May 2014 22:49:58 +0200, Thomas Neidhart wrote:
On 05/01/2014 10:31 PM, Gilles wrote:
Hi.
I don't like most of the changes performed on the Javadoc; most of
them
are going in the wrong direction IMHO, the most severe being the use
of
HTML entities rather than using MathJax.[1]
well, this does not really come as a surprise.
But seriously, about which changes are you talking?
There are 5 groups of changes which have been performed so far:
* replace br/ with p tags
Trigerring an error on self-closing (and valid XML) tags seems
utterly stupid. [There might be some deeper reasons which I'm not
aware of at this point, since those nice Java 8 features are
totally new to me.]
* escape angle brackets (, ) with the corresponding HTML entities
Does Java 8 refuse angle brackets enclosed in {@code ...} tags?
* remove unneeded /p tags where java 8 javadoc complained
In XML, closing tags are never unneeded, they are required; so it
looks like Java 8 decided to be XML non-compliant.
If this is so, my opinion is to not use p anymore!
* add code tags within pre blocks as sub was not allowed
otherwise
* fix wrong/missing closing of tags (mostly ol, ul, code, li)
The only change being potentially controversial wrt readability are
the
angle brackets, but there are already many cases where the entities
are
used and this is only good practice and making it consistent in the
whole codebase.
I don't agree that reducing legibility is good practise.
Last time I checked W3C was trying to make HTML a valid XML
language;
now from what I read in this commit, Java 8 insists on being invalid
XML...
Since when was it decided to comply with Java 8 despite that it does
not
seem to be an obvious move?
Feel free to revert my change, I was only determined to avoid
potential
problems with the 3.3 vote as some people build with Java 8 and
report
errors with it.
As the build with Java 8 is broken anyway (due to findbugs), it was a
wasted effort for now, thus I stopped in the middle of it.
Until there is agreement on a way out, I think that we should have
followed the route proposed here:
http://blog.joda.org/2014/02/turning-off-doclint-in-jdk-8-javadoc.html
(i.e. disable the enforcement of the new rules).
Well, I tried that, but the setting did not seem to work with java 7,
thus I had to remove it again.
Then, as I indicated in the [vote] post, we should just not support
Java 8 for the time being, and ask people to open appropriate issues
for the things they wish to be fixed.
Why should we jump because Oracle made Java 8 non compatible with
Java 7?
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:
Re: [SANDBOX][BEANUTILS2] Changing code style
+1 Gary On Fri, May 2, 2014 at 6:53 AM, Benedikt Ritter brit...@apache.org wrote: Hi all, BeanUtils2 uses the maven code style rules. Every now and then I have to reject patches because they don't follow these conventions. I'd like to change the formatting rules to a more standard rule set for the following reasons: - maven style is very verbose, since it uses a lot of spaces and curly braces have to be placed on new lines - a great majority of our components uses the Sun/Eclipse formatting with spaces - Setting up IDEs like IntelliJ or Eclipse is easier with the Sun/Eclipse style, because the only thing you have to change is the tab policy. Using the maven style implies that one has to import the rule set. If no one objects, I'll reformat the source code and update the check style rules. Regards, Benedikt -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [LANG] Algorithm for fuzzy string matching
So, keep SU as a kitchen sink and refactor for 4.0? I'm OK with that. Gary On Fri, May 2, 2014 at 7:03 AM, Benedikt Ritter brit...@apache.org wrote: Hi Gary, we had a discussion about this some time ago, where I proposed to create a new class (let's call it StringMetrics) and move Levenshtein and Jaro Winkler to it. We decided not to do this in 3.x, since SU already has 180+ methods which will have to be split up in the next major release. Benedikt 2014-05-02 13:00 GMT+02:00 Gary Gregory garydgreg...@gmail.com: Do we really want this in SU or should it live in its own class? Gary div Original message /divdivFrom: Benedikt Ritter brit...@apache.org /divdivDate:05/02/2014 04:15 (GMT-05:00) /divdivTo: Commons Developers List dev@commons.apache.org /divdivSubject: Re: [LANG] Algorithm for fuzzy string matching /divdiv /divSince nobody had objections against adding this, I'll apply this patch. Benedikt 2014-04-28 17:47 GMT+02:00 Benedikt Ritter brit...@apache.org: Hi all, we have a nice PR for StringUtils at github: https://github.com/apache/commons-lang/pull/20 It adds a new string matching algorithm to StringUtils, that calculates a score for the similarity between to strings. This kind of fuzzy matching is known from editors like Sublime Text, Text Mate or Atom. I think this is a very useful features, but as the contributor points out, the is no scientific paper or thesis that provides a reference for the implementation. So this is not _the one_ implementation of a fuzzy string matching score, like our implementations of the Levenshtein or Jaro-Winkler algorithms. So before adding this, I'd like to hear how others feel about this feature. Regards, Benedikt -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: JDK8 compatible javadoc
On Fri, May 2, 2014 at 9:43 AM, Emmanuel Bourg ebo...@apache.org wrote: Le 02/05/2014 15:37, Gary Gregory a écrit : So the plan is to let each [component] pick how they want to deal with Java 8 right? As a side note, I'd like to emphasize that our source code is being recompiled by downstream packagers, most notably Linux distributions. Fedora 21 will default to Java 8 and Debian is working toward this goal, so it would be nice if our components do compile and work on Java 8. For now math, exec and bcel aren't working properly. Which why I favor fixing (which I've been doing here and there, a little at a time) Javadocs for plain builds with Java 8, sans turning doclint off. Gary Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [csv] Release planning for commons-csv
+1 to keep the discussion going with or without patches. We need to get a 1.0 out the door. Gary On Fri, May 2, 2014 at 4:57 AM, Gabriel Reid gabriel.r...@gmail.com wrote: Hi Benedikt, Thanks for the feedback. My comments are inlined below. On Fri, May 2, 2014 at 9:41 AM, Benedikt Ritter brit...@apache.org wrote: 2014-05-02 8:15 GMT+02:00 Gabriel Reid gabriel.r...@gmail.com: If there are open issues that are specifically standing in the way of a release, I would be happy to assist in attempting to resolve them if someone can point me in the right direction. we are close to a release for a long time now. However we are still looking for a solution to CSV-35 [1] and CSV-58 [2]. There have been long discussions around this issues and to me it looks like there still is no solution. If you have a smart idea feel free to create a patch. Thanks for pointing these out. I'll certainly take a look at them in greater detail to see if there's anything I can see or think of. At commons we are crazy about binary compatibility ;-) We're going through a lot a trouble to make sure you won't run into jar hell when using our components. This is why you can use commons lang 2.6 alongside commons lang 3.3.2 in the same class path. To achieve this, we change the maven coordinates as well as the package coordinates when we break binary compatibility. [snip] The problem is, even if we declare this release as an alpha release or what ever, people will start using it. And all of a sudden you have commons-csv 0.1 in your class path through transitive dependencies but you really need 1.0 which isn't compatible. You're app has been broken by a rushed out release with an unstable API... Understood, and I certainly think that worry about binary compatibility is a worthy cause (and certainly don't want to try to convince the project to go against that principle). However, I think that there are some additional things to consider here as well. Both of the blocking issues are over two years old, with very little activity in the past 6 months. There are currently people making use of commons-csv by doing things like copying the code into their own repo, or making their own release build. These are the same users who are intended to be protected by the promise of binary compatibility, but they (and projects that make use of their published artifacts) will suffer from the same consequences that you outlined by breaking binary incompatibility. The argument could of course be made that people shouldn't be doing things like making their own build or folding the commons-csv code into their own projects, but the fact is that people are doing this (just like people will use a 0.1 release, despite any kinds of warnings about possible future incompatibilites). Additionally, the two issues in question are both classified as bugs, and it appears that both will (or at least could be) eventually be resolved by adding additional configuration methods. This addition of additional configuration methods won't break backwards compatibility. Basically my points are: * by delaying a release to protect users, the same users are doing things which bring the same (or even worse) risks that the delayed release is supposed to be protecting them from * it appears to be possible to resolve the two blocking issues in the future without breaking binary compatibility - Gabriel - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [jcs] building with JSR-107 TCK
On 02.05.14 10:13, Jean-Louis MONTEIRO wrote: He he, sure :) Here is the error even in Java 7. ERROR] /Users/jlmonteiro/devs/asf/commons/proper/jcs/trunk/commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/JCSCache.java:[92,129] cannot find symbol symbol: class MyThreadFactory location: class org.apache.commons.jcs.utils.threadpool.ThreadPoolManager [ERROR] /Users/jlmonteiro/devs/asf/commons/proper/jcs/trunk/commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/JCSCache.java:[93,68] cannot find symbol symbol: class MyThreadFactory location: class org.apache.commons.jcs.utils.threadpool.ThreadPoolManager Yeah, I removed the thread factories that were scattered all over the place and created a separate class. I did some other stuff so I could not commit everything. It will be fixed soon. Bye, Thomas. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[continuum] BUILD FAILURE: Apache Commons JCS - Apache Commons (Group (shared) Maven 3 Build Definition (Java 1.6))
Online report : https://continuum-ci.apache.org/continuum/buildResult.action?buildId=30072projectId=286 Build statistics: State: Failed Previous State: Failed Started at: Fri 2 May 2014 14:20:52 + Finished at: Fri 2 May 2014 14:24:56 + Total time: 4m 4s Build Trigger: Schedule Build Number: 1 Exit code: 1 Building machine hostname: continuum-vm Operating system : Linux(unknown) Java Home version : java version 1.6.0_27 OpenJDK Runtime Environment (IcedTea6 1.12.6) (6b27-1.12.6-1ubuntu0.12.04.4) OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode) Builder version : Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 13:51:28+) Maven home: /opt/apache-maven-3.0.5 Java version: 1.6.0_27, vendor: Sun Microsystems Inc. Java home: /usr/lib/jvm/java-6-openjdk-amd64/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux, version: 3.2.0-53-generic, arch: amd64, family: unix SCM Changes: Changed: tv @ Fri 2 May 2014 14:17:38 + Comment: Simplify event handling, general cleanup Files changed: /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/disk/PurgatoryElement.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/lateral/LateralCacheAbstractManager.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/lateral/socket/tcp/LateralTCPCacheFactory.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/CacheElement.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/CacheElementSerialized.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/ElementAttributes.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/behavior/IElementAttributes.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/control/CompositeCache.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/control/CompositeCacheConfigurator.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/control/CompositeCacheManager.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/control/event/ElementEventQueue.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/control/event/behavior/IElementEventHandler.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/control/event/behavior/IElementEventQueue.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/AbstractMemoryCache.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/shrinking/ShrinkerThread.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/utils/discovery/UDPDiscoveryManager.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/remote/server/BasicRemoteCacheClientServerUnitTest.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/test/java/org/apache/commons/jcs/engine/control/CompositeCacheDiskUsageUnitTest.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/test/java/org/apache/commons/jcs/engine/control/CompositeCacheUnitTest.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/test/java/org/apache/commons/jcs/engine/control/MockCompositeCacheManager.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/test/java/org/apache/commons/jcs/engine/memory/fifo/FIFOMemoryCacheUnitTest.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/test/java/org/apache/commons/jcs/engine/memory/shrinking/ShrinkerThreadUnitTest.java ( 1591925 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode -Pjava-1.6 -Dgpg.skip -Prelease Build Fresh: false Always Build: false Default Build Definition: true Schedule:
[continuum] BUILD FAILURE: Apache Commons JCS - Apache Commons ()
Online report : https://continuum-ci.apache.org/continuum/buildResult.action?buildId=30073projectId=286 Build statistics: State: Failed Previous State: Failed Started at: Fri 2 May 2014 15:00:04 + Finished at: Fri 2 May 2014 15:04:35 + Total time: 4m 30s Build Trigger: Schedule Build Number: 1 Exit code: 1 Building machine hostname: continuum-vm Operating system : Linux(unknown) Java Home version : java version 1.7.0_25 OpenJDK Runtime Environment (IcedTea 2.3.10) (7u25-2.3.10-1ubuntu0.12.04.2) OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode) Builder version : Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 13:51:28+) Maven home: /opt/apache-maven-3.0.5 Java version: 1.7.0_25, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux, version: 3.2.0-53-generic, arch: amd64, family: unix SCM Changes: Changed: tv @ Fri 2 May 2014 14:17:38 + Comment: Simplify event handling, general cleanup Files changed: /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/disk/PurgatoryElement.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/lateral/LateralCacheAbstractManager.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/lateral/socket/tcp/LateralTCPCacheFactory.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/CacheElement.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/CacheElementSerialized.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/ElementAttributes.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/behavior/IElementAttributes.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/control/CompositeCache.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/control/CompositeCacheConfigurator.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/control/CompositeCacheManager.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/control/event/ElementEventQueue.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/control/event/behavior/IElementEventHandler.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/control/event/behavior/IElementEventQueue.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/AbstractMemoryCache.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/shrinking/ShrinkerThread.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/utils/discovery/UDPDiscoveryManager.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/remote/server/BasicRemoteCacheClientServerUnitTest.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/test/java/org/apache/commons/jcs/engine/control/CompositeCacheDiskUsageUnitTest.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/test/java/org/apache/commons/jcs/engine/control/CompositeCacheUnitTest.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/test/java/org/apache/commons/jcs/engine/control/MockCompositeCacheManager.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/test/java/org/apache/commons/jcs/engine/memory/fifo/FIFOMemoryCacheUnitTest.java ( 1591925 ) /commons/proper/jcs/trunk/commons-jcs-core/src/test/java/org/apache/commons/jcs/engine/memory/shrinking/ShrinkerThreadUnitTest.java ( 1591925 ) Changed: tv @ Fri 2 May 2014 14:24:19 + Comment: Centralize thread factories, fix formatting Files changed: /commons/proper/jcs/trunk/commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/JCSCache.java ( 1591929 ) /commons/proper/jcs/trunk/commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/JCSCachingManager.java ( 1591929 ) /commons/proper/jcs/trunk/commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/JCSElement.java ( 1591929 )
[jcs] JCache implementation review
Hi folks, I took some time to look over the code of the JCache implementation and I have some suggestions for simplification (under the assumption that I understood the intention correctly). - JCS does not implement the same model of cache element expiry, however a few more existing features could be used. The question is how strict are the requirements of the JSR. I think that most of the functionality of JCSElement is already there in ICacheElement. - I'd like to move Statistics to the core. The cache statistics of JCS are too scattered and this class would very much improve this situation. - JCS has element event handling built-in. It works, however, for expiry and spool events only. I made a few modifications so that the additional events for create, update etc. can be added easily. - The code produces quite a few warnings referring to type safety and possible NPEs. I guess this could be improved. - The code of the core and jcache modules compiles fine here and all tests pass (MacOS 10.6.8, JDK 1.6.0_65). The 1.6 compiler needed some additional support with CacheTest, however. - Wonder where the commons-math3 dependency comes from? Bye, Thomas. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jcs] JCache implementation review
Hi globally a big +1 some more remarks inline 2014-05-02 17:13 GMT+02:00 Thomas Vandahl t...@apache.org: Hi folks, I took some time to look over the code of the JCache implementation and I have some suggestions for simplification (under the assumption that I understood the intention correctly). - JCS does not implement the same model of cache element expiry, however a few more existing features could be used. The question is how strict are the requirements of the JSR. I think that most of the functionality of JCSElement is already there in ICacheElement. would be awesome to merge if you think it is possible. strict part can be tested running TCKs (once the few missing assertNotNull and the shutdown are in place - didnt check today). Only interceptor related ones should fail. If ExpiryTest fails it is a regression. - I'd like to move Statistics to the core. The cache statistics of JCS are too scattered and this class would very much improve this situation. Ok. Was expecting something to compute distributed statistics and not only local ones. Do you think we can without breaking the whole project? - JCS has element event handling built-in. It works, however, for expiry and spool events only. I made a few modifications so that the additional events for create, update etc. can be added easily. great news! If we can move listeners to just be internal handler listener adapters it would be awesome. - The code produces quite a few warnings referring to type safety and possible NPEs. I guess this could be improved. go for it when you see it :) - The code of the core and jcache modules compiles fine here and all tests pass (MacOS 10.6.8, JDK 1.6.0_65). The 1.6 compiler needed some additional support with CacheTest, however. - Wonder where the commons-math3 dependency comes from? shouldn't be needed IMHO 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
[continuum] BUILD FAILURE: Apache Commons JCS - Apache Commons (Group (shared) Maven 3 Build Definition (Java 1.6))
Online report : https://continuum-ci.apache.org/continuum/buildResult.action?buildId=30076projectId=286 Build statistics: State: Failed Previous State: Failed Started at: Fri 2 May 2014 15:20:34 + Finished at: Fri 2 May 2014 15:24:16 + Total time: 3m 42s Build Trigger: Schedule Build Number: 1 Exit code: 1 Building machine hostname: continuum-vm Operating system : Linux(unknown) Java Home version : java version 1.6.0_27 OpenJDK Runtime Environment (IcedTea6 1.12.6) (6b27-1.12.6-1ubuntu0.12.04.4) OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode) Builder version : Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 13:51:28+) Maven home: /opt/apache-maven-3.0.5 Java version: 1.6.0_27, vendor: Sun Microsystems Inc. Java home: /usr/lib/jvm/java-6-openjdk-amd64/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux, version: 3.2.0-53-generic, arch: amd64, family: unix SCM Changes: Changed: tv @ Fri 2 May 2014 14:30:35 + Comment: Fix typo Files changed: /commons/proper/jcs/trunk/commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/cdi/MakeJCacheCDIInterceptorFriendly.java (from /commons/proper/jcs/trunk/commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/cdi/MakeJCacheCDIIntercetporFriendly.java:1591679) ( 1591931 ) /commons/proper/jcs/trunk/commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/cdi/MakeJCacheCDIIntercetporFriendly.java ( 1591931 ) Changed: tv @ Fri 2 May 2014 14:38:13 + Comment: Remove obsolete synchronization Files changed: /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/control/event/ElementEventQueue.java ( 1591932 ) Changed: tv @ Fri 2 May 2014 15:05:16 + Comment: Give some help to the poor 1.6 compiler Files changed: /commons/proper/jcs/trunk/commons-jcs-jcache/src/test/java/org/apache/commons/jcs/jcache/CacheTest.java ( 1591942 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode -Pjava-1.6 -Dgpg.skip -Prelease Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Maven 3.0.5 Description: Group (shared) Maven 3 Build Definition (Java 1.6) Test Summary: Tests: 379 Failures: 4 Errors: 0 Success Rate: 98 Total time: 133.89098 Test Failures: BasicRemoteCacheClientServerUnitTest test1SinglePut : java.lang.AssertionError java.lang.AssertionError: Cache is alive expected:ALIVE but was:ERROR at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:743) at org.junit.Assert.assertEquals(Assert.java:118) at org.apache.commons.jcs.auxiliary.remote.server.BasicRemoteCacheClientServerUnitTest.test1SinglePut(BasicRemoteCacheClientServerUnitTest.java:118) test2PutRemove : java.lang.AssertionError java.lang.AssertionError: Cache is alive expected:ALIVE but was:ERROR at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:743) at org.junit.Assert.assertEquals(Assert.java:118) at org.apache.commons.jcs.auxiliary.remote.server.BasicRemoteCacheClientServerUnitTest.test2PutRemove(BasicRemoteCacheClientServerUnitTest.java:168) test3PutAndListen : java.lang.AssertionError java.lang.AssertionError: Cache is alive expected:ALIVE but was:ERROR at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:743) at org.junit.Assert.assertEquals(Assert.java:118) at org.apache.commons.jcs.auxiliary.remote.server.BasicRemoteCacheClientServerUnitTest.test3PutAndListen(BasicRemoteCacheClientServerUnitTest.java:226) test4PutaMultipleAndListen : java.lang.AssertionError java.lang.AssertionError: Cache is alive expected:ALIVE but was:ERROR at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:743) at org.junit.Assert.assertEquals(Assert.java:118) at
[continuum] BUILD FAILURE: Apache Commons JCS - Apache Commons ()
Online report : https://continuum-ci.apache.org/continuum/buildResult.action?buildId=30077projectId=286 Build statistics: State: Failed Previous State: Failed Started at: Fri 2 May 2014 16:00:05 + Finished at: Fri 2 May 2014 16:04:12 + Total time: 4m 6s Build Trigger: Schedule Build Number: 1 Exit code: 1 Building machine hostname: continuum-vm Operating system : Linux(unknown) Java Home version : java version 1.7.0_25 OpenJDK Runtime Environment (IcedTea 2.3.10) (7u25-2.3.10-1ubuntu0.12.04.2) OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode) Builder version : Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 13:51:28+) Maven home: /opt/apache-maven-3.0.5 Java version: 1.7.0_25, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux, version: 3.2.0-53-generic, arch: amd64, family: unix SCM Changes: Changed: tv @ Fri 2 May 2014 15:05:16 + Comment: Give some help to the poor 1.6 compiler Files changed: /commons/proper/jcs/trunk/commons-jcs-jcache/src/test/java/org/apache/commons/jcs/jcache/CacheTest.java ( 1591942 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean test Arguments: --batch-mode -Pjava-1.7 Build Fresh: false Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Maven 3.0.5 with Java 7 Description: Test Summary: Tests: 379 Failures: 4 Errors: 0 Success Rate: 98 Total time: 143.52599 Test Failures: BasicRemoteCacheClientServerUnitTest test1SinglePut : java.lang.AssertionError java.lang.AssertionError: Cache is alive expected:ALIVE but was:ERROR at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:743) at org.junit.Assert.assertEquals(Assert.java:118) at org.apache.commons.jcs.auxiliary.remote.server.BasicRemoteCacheClientServerUnitTest.test1SinglePut(BasicRemoteCacheClientServerUnitTest.java:118) test2PutRemove : java.lang.AssertionError java.lang.AssertionError: Cache is alive expected:ALIVE but was:ERROR at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:743) at org.junit.Assert.assertEquals(Assert.java:118) at org.apache.commons.jcs.auxiliary.remote.server.BasicRemoteCacheClientServerUnitTest.test2PutRemove(BasicRemoteCacheClientServerUnitTest.java:168) test3PutAndListen : java.lang.AssertionError java.lang.AssertionError: Cache is alive expected:ALIVE but was:ERROR at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:743) at org.junit.Assert.assertEquals(Assert.java:118) at org.apache.commons.jcs.auxiliary.remote.server.BasicRemoteCacheClientServerUnitTest.test3PutAndListen(BasicRemoteCacheClientServerUnitTest.java:226) test4PutaMultipleAndListen : java.lang.AssertionError java.lang.AssertionError: Cache is alive expected:ALIVE but was:ERROR at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:743) at org.junit.Assert.assertEquals(Assert.java:118) at org.apache.commons.jcs.auxiliary.remote.server.BasicRemoteCacheClientServerUnitTest.test4PutaMultipleAndListen(BasicRemoteCacheClientServerUnitTest.java:280) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] JDK 8 2.1-SNAPSHOT
Yes, I see the same problem. (And besides that it seems PMD and findbugs make problems for Java8, too.) bernd Am 02.05.2014 um 13:27 schrieb Schalk Cronjé ysb...@gmail.com: Does anyone else have failures building VFS 2.1 with JDK8 (SVN rev 1591869)? I am seeing this test failure building on Mac. --- Test set: org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest --- Tests run: 9, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.012 sec FAILURE! - in org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest testSmallFS(org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest) Time elapsed: 0.007 sec ERROR! java.lang.IllegalArgumentException: Self-suppression not permitted at org.apache.commons.vfs2.provider.ram.RamFileObject.resize(RamFileObject.java:277) at org.apache.commons.vfs2.provider.ram.RamFileOutputStream.write(RamFileOutputStream.java:68) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) at org.apache.commons.vfs2.util.MonitorOutputStream.flush(MonitorOutputStream.java:114) at java.io.FilterOutputStream.close(FilterOutputStream.java:158) at org.apache.commons.vfs2.util.MonitorOutputStream.close(MonitorOutputStream.java:54) at org.apache.commons.vfs2.provider.DefaultFileContent$FileContentOutputStream.close(DefaultFileContent.java:711) at org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest.testSmallFS(CustomRamProviderTest.java:264) -- Schalk W. Cronjé @ysb33r - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jcs] JCache implementation review
one more thing we can discuss are the close() methods of JCache impl. Did a first version but sometimes closing a JCache component will remove all items of the cache. Not sure it is intended in distributed mode. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-05-02 17:17 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com: Hi globally a big +1 some more remarks inline 2014-05-02 17:13 GMT+02:00 Thomas Vandahl t...@apache.org: Hi folks, I took some time to look over the code of the JCache implementation and I have some suggestions for simplification (under the assumption that I understood the intention correctly). - JCS does not implement the same model of cache element expiry, however a few more existing features could be used. The question is how strict are the requirements of the JSR. I think that most of the functionality of JCSElement is already there in ICacheElement. would be awesome to merge if you think it is possible. strict part can be tested running TCKs (once the few missing assertNotNull and the shutdown are in place - didnt check today). Only interceptor related ones should fail. If ExpiryTest fails it is a regression. - I'd like to move Statistics to the core. The cache statistics of JCS are too scattered and this class would very much improve this situation. Ok. Was expecting something to compute distributed statistics and not only local ones. Do you think we can without breaking the whole project? - JCS has element event handling built-in. It works, however, for expiry and spool events only. I made a few modifications so that the additional events for create, update etc. can be added easily. great news! If we can move listeners to just be internal handler listener adapters it would be awesome. - The code produces quite a few warnings referring to type safety and possible NPEs. I guess this could be improved. go for it when you see it :) - The code of the core and jcache modules compiles fine here and all tests pass (MacOS 10.6.8, JDK 1.6.0_65). The 1.6 compiler needed some additional support with CacheTest, however. - Wonder where the commons-math3 dependency comes from? shouldn't be needed IMHO 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: [LANG] Algorithm for fuzzy string matching
Yes, that would be the plan, I guess :-) 2014-05-02 15:58 GMT+02:00 Gary Gregory garydgreg...@gmail.com: So, keep SU as a kitchen sink and refactor for 4.0? I'm OK with that. Gary On Fri, May 2, 2014 at 7:03 AM, Benedikt Ritter brit...@apache.org wrote: Hi Gary, we had a discussion about this some time ago, where I proposed to create a new class (let's call it StringMetrics) and move Levenshtein and Jaro Winkler to it. We decided not to do this in 3.x, since SU already has 180+ methods which will have to be split up in the next major release. Benedikt 2014-05-02 13:00 GMT+02:00 Gary Gregory garydgreg...@gmail.com: Do we really want this in SU or should it live in its own class? Gary div Original message /divdivFrom: Benedikt Ritter brit...@apache.org /divdivDate:05/02/2014 04:15 (GMT-05:00) /divdivTo: Commons Developers List dev@commons.apache.org /divdivSubject: Re: [LANG] Algorithm for fuzzy string matching /divdiv /divSince nobody had objections against adding this, I'll apply this patch. Benedikt 2014-04-28 17:47 GMT+02:00 Benedikt Ritter brit...@apache.org: Hi all, we have a nice PR for StringUtils at github: https://github.com/apache/commons-lang/pull/20 It adds a new string matching algorithm to StringUtils, that calculates a score for the similarity between to strings. This kind of fuzzy matching is known from editors like Sublime Text, Text Mate or Atom. I think this is a very useful features, but as the contributor points out, the is no scientific paper or thesis that provides a reference for the implementation. So this is not _the one_ implementation of a fuzzy string matching score, like our implementations of the Levenshtein or Jaro-Winkler algorithms. So before adding this, I'd like to hear how others feel about this feature. Regards, Benedikt -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Re: [SANDBOX][BEANUTILS2] Property expressions
So you're saying we should leave this out of BU2? 2014-05-02 12:55 GMT+02:00 Gary Gregory garydgreg...@gmail.com: There is also our own jxpath. Gary div Original message /divdivFrom: Benedikt Ritter brit...@apache.org /divdivDate:05/02/2014 06:40 (GMT-05:00) /divdivTo: Commons Developers List dev@commons.apache.org /divdivSubject: [SANDBOX][BEANUTILS2] Property expressions /divdiv /divHi all, one of the goal of BeanUtils2 is to provide the same functionality as BeanUtils1. In BeanUtils1 you can do something like this: BeanUtils.getProperty(person, address.city.zipCode); This would be translated into: person.getAddress().getCity().getZipCode(); The same can be done with mapped and indexed properties: BeanUtils.getProperty(person, contact(5).name); which would be translated to: person.getContact(5).getName(); BeanUtils2 provides a fluent API where the first example would be done via: on(person).get(address).get(city).get(zipCode) and the second: on(person).getIndexed(contact).at(5).get(name) We are currently thinking about how we can implement the property expressions. We are discussing this in SANDBOX-464 [1] and there is already a patch. I'm currently unsure whether we should allow mixing up the fluent API and property expressions. The contributor makes some good examples of what kind of awful code could be created: on(addressBook).get(provider(google).contact[5] ).getMapped(address).with(home).get(street.yetAnotherNestedProperty) on the other hand I don't want to force people into doing stuff like this: String path = ...int pos = ... on(bean).get(path + [ + pos + ]); Currently I'm tempted to allow mixing up both API styles, but I'd like to here your opinion first. Benedikt [1] https://issues.apache.org/jira/browse/SANDBOX-464 -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Re: [csv] Release planning for commons-csv
So you're saying we should release 1.0 from the current trunk? I would volunteer to RM. 2014-05-02 16:02 GMT+02:00 Gary Gregory garydgreg...@gmail.com: +1 to keep the discussion going with or without patches. We need to get a 1.0 out the door. Gary On Fri, May 2, 2014 at 4:57 AM, Gabriel Reid gabriel.r...@gmail.com wrote: Hi Benedikt, Thanks for the feedback. My comments are inlined below. On Fri, May 2, 2014 at 9:41 AM, Benedikt Ritter brit...@apache.org wrote: 2014-05-02 8:15 GMT+02:00 Gabriel Reid gabriel.r...@gmail.com: If there are open issues that are specifically standing in the way of a release, I would be happy to assist in attempting to resolve them if someone can point me in the right direction. we are close to a release for a long time now. However we are still looking for a solution to CSV-35 [1] and CSV-58 [2]. There have been long discussions around this issues and to me it looks like there still is no solution. If you have a smart idea feel free to create a patch. Thanks for pointing these out. I'll certainly take a look at them in greater detail to see if there's anything I can see or think of. At commons we are crazy about binary compatibility ;-) We're going through a lot a trouble to make sure you won't run into jar hell when using our components. This is why you can use commons lang 2.6 alongside commons lang 3.3.2 in the same class path. To achieve this, we change the maven coordinates as well as the package coordinates when we break binary compatibility. [snip] The problem is, even if we declare this release as an alpha release or what ever, people will start using it. And all of a sudden you have commons-csv 0.1 in your class path through transitive dependencies but you really need 1.0 which isn't compatible. You're app has been broken by a rushed out release with an unstable API... Understood, and I certainly think that worry about binary compatibility is a worthy cause (and certainly don't want to try to convince the project to go against that principle). However, I think that there are some additional things to consider here as well. Both of the blocking issues are over two years old, with very little activity in the past 6 months. There are currently people making use of commons-csv by doing things like copying the code into their own repo, or making their own release build. These are the same users who are intended to be protected by the promise of binary compatibility, but they (and projects that make use of their published artifacts) will suffer from the same consequences that you outlined by breaking binary incompatibility. The argument could of course be made that people shouldn't be doing things like making their own build or folding the commons-csv code into their own projects, but the fact is that people are doing this (just like people will use a 0.1 release, despite any kinds of warnings about possible future incompatibilites). Additionally, the two issues in question are both classified as bugs, and it appears that both will (or at least could be) eventually be resolved by adding additional configuration methods. This addition of additional configuration methods won't break backwards compatibility. Basically my points are: * by delaying a release to protect users, the same users are doing things which bring the same (or even worse) risks that the delayed release is supposed to be protecting them from * it appears to be possible to resolve the two blocking issues in the future without breaking binary compatibility - Gabriel - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Re: JDK8 compatible javadoc
so it would be nice if our components do compile and work on Java 8 It does of course. But if you compile with java8 then it _might_ not work with older java versions. So it's fine for packages built by Fedora FOR Fedora. But those jars might not work on any other linux distro. Which is ok from the Linux distro side, but a bit unexpected from a Java perspective... LieGrue, strub On Friday, 2 May 2014, 15:44, Emmanuel Bourg ebo...@apache.org wrote: Le 02/05/2014 15:37, Gary Gregory a écrit : So the plan is to let each [component] pick how they want to deal with Java 8 right? As a side note, I'd like to emphasize that our source code is being recompiled by downstream packagers, most notably Linux distributions. Fedora 21 will default to Java 8 and Debian is working toward this goal, so it would be nice if our components do compile and work on Java 8. For now math, exec and bcel aren't working properly. Emmanuel Bourg - 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: [SANDBOX][BEANUTILS2] Property expressions
Nah, I'm just talking around the water cooler, thinking aloud... Gary div Original message /divdivFrom: Benedikt Ritter brit...@apache.org /divdivDate:05/02/2014 12:59 (GMT-05:00) /divdivTo: Commons Developers List dev@commons.apache.org /divdivSubject: Re: [SANDBOX][BEANUTILS2] Property expressions /divdiv /divSo you're saying we should leave this out of BU2? 2014-05-02 12:55 GMT+02:00 Gary Gregory garydgreg...@gmail.com: There is also our own jxpath. Gary div Original message /divdivFrom: Benedikt Ritter brit...@apache.org /divdivDate:05/02/2014 06:40 (GMT-05:00) /divdivTo: Commons Developers List dev@commons.apache.org /divdivSubject: [SANDBOX][BEANUTILS2] Property expressions /divdiv /divHi all, one of the goal of BeanUtils2 is to provide the same functionality as BeanUtils1. In BeanUtils1 you can do something like this: BeanUtils.getProperty(person, address.city.zipCode); This would be translated into: person.getAddress().getCity().getZipCode(); The same can be done with mapped and indexed properties: BeanUtils.getProperty(person, contact(5).name); which would be translated to: person.getContact(5).getName(); BeanUtils2 provides a fluent API where the first example would be done via: on(person).get(address).get(city).get(zipCode) and the second: on(person).getIndexed(contact).at(5).get(name) We are currently thinking about how we can implement the property expressions. We are discussing this in SANDBOX-464 [1] and there is already a patch. I'm currently unsure whether we should allow mixing up the fluent API and property expressions. The contributor makes some good examples of what kind of awful code could be created: on(addressBook).get(provider(google).contact[5] ).getMapped(address).with(home).get(street.yetAnotherNestedProperty) on the other hand I don't want to force people into doing stuff like this: String path = ...int pos = ... on(bean).get(path + [ + pos + ]); Currently I'm tempted to allow mixing up both API styles, but I'd like to here your opinion first. Benedikt [1] https://issues.apache.org/jira/browse/SANDBOX-464 -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Re: [csv] Release planning for commons-csv
The question is would fixing these two issues break compatibility? We have three compatibility levels: binary, source, and behavior. I'm guessing we would be ok on source and binary. Would the behavior be different enough to mean the version that fixes these should be 2.0? I'm guessing no. Thoughs? Comments? Gary div Original message /divdivFrom: Benedikt Ritter brit...@apache.org /divdivDate:05/02/2014 13:00 (GMT-05:00) /divdivTo: Commons Developers List dev@commons.apache.org /divdivSubject: Re: [csv] Release planning for commons-csv /divdiv /divSo you're saying we should release 1.0 from the current trunk? I would volunteer to RM. 2014-05-02 16:02 GMT+02:00 Gary Gregory garydgreg...@gmail.com: +1 to keep the discussion going with or without patches. We need to get a 1.0 out the door. Gary On Fri, May 2, 2014 at 4:57 AM, Gabriel Reid gabriel.r...@gmail.com wrote: Hi Benedikt, Thanks for the feedback. My comments are inlined below. On Fri, May 2, 2014 at 9:41 AM, Benedikt Ritter brit...@apache.org wrote: 2014-05-02 8:15 GMT+02:00 Gabriel Reid gabriel.r...@gmail.com: If there are open issues that are specifically standing in the way of a release, I would be happy to assist in attempting to resolve them if someone can point me in the right direction. we are close to a release for a long time now. However we are still looking for a solution to CSV-35 [1] and CSV-58 [2]. There have been long discussions around this issues and to me it looks like there still is no solution. If you have a smart idea feel free to create a patch. Thanks for pointing these out. I'll certainly take a look at them in greater detail to see if there's anything I can see or think of. At commons we are crazy about binary compatibility ;-) We're going through a lot a trouble to make sure you won't run into jar hell when using our components. This is why you can use commons lang 2.6 alongside commons lang 3.3.2 in the same class path. To achieve this, we change the maven coordinates as well as the package coordinates when we break binary compatibility. [snip] The problem is, even if we declare this release as an alpha release or what ever, people will start using it. And all of a sudden you have commons-csv 0.1 in your class path through transitive dependencies but you really need 1.0 which isn't compatible. You're app has been broken by a rushed out release with an unstable API... Understood, and I certainly think that worry about binary compatibility is a worthy cause (and certainly don't want to try to convince the project to go against that principle). However, I think that there are some additional things to consider here as well. Both of the blocking issues are over two years old, with very little activity in the past 6 months. There are currently people making use of commons-csv by doing things like copying the code into their own repo, or making their own release build. These are the same users who are intended to be protected by the promise of binary compatibility, but they (and projects that make use of their published artifacts) will suffer from the same consequences that you outlined by breaking binary incompatibility. The argument could of course be made that people shouldn't be doing things like making their own build or folding the commons-csv code into their own projects, but the fact is that people are doing this (just like people will use a 0.1 release, despite any kinds of warnings about possible future incompatibilites). Additionally, the two issues in question are both classified as bugs, and it appears that both will (or at least could be) eventually be resolved by adding additional configuration methods. This addition of additional configuration methods won't break backwards compatibility. Basically my points are: * by delaying a release to protect users, the same users are doing things which bring the same (or even worse) risks that the delayed release is supposed to be protecting them from * it appears to be possible to resolve the two blocking issues in the future without breaking binary compatibility - Gabriel - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter
Re: JDK8 compatible javadoc
It's a distro's business if they want to restrict usage to a given Java version. It's our job to make sure it is not only possible but easy. Build out of the box and all... Gary div Original message /divdivFrom: Mark Struberg strub...@yahoo.de /divdivDate:05/02/2014 13:18 (GMT-05:00) /divdivTo: Commons Developers List dev@commons.apache.org /divdivSubject: Re: JDK8 compatible javadoc /divdiv /divso it would be nice if our components do compile and work on Java 8 It does of course. But if you compile with java8 then it _might_ not work with older java versions. So it's fine for packages built by Fedora FOR Fedora. But those jars might not work on any other linux distro. Which is ok from the Linux distro side, but a bit unexpected from a Java perspective... LieGrue, strub On Friday, 2 May 2014, 15:44, Emmanuel Bourg ebo...@apache.org wrote: Le 02/05/2014 15:37, Gary Gregory a écrit : So the plan is to let each [component] pick how they want to deal with Java 8 right? As a side note, I'd like to emphasize that our source code is being recompiled by downstream packagers, most notably Linux distributions. Fedora 21 will default to Java 8 and Debian is working toward this goal, so it would be nice if our components do compile and work on Java 8. For now math, exec and bcel aren't working properly. Emmanuel Bourg - 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: [csv] Release planning for commons-csv
API breakage would be 2.0. Do we know yet that fixing those issue would send use to 2.0? Thanks -D On Fri, May 2, 2014 at 11:02 AM, Gary Gregory garydgreg...@gmail.comwrote: The question is would fixing these two issues break compatibility? We have three compatibility levels: binary, source, and behavior. I'm guessing we would be ok on source and binary. Would the behavior be different enough to mean the version that fixes these should be 2.0? I'm guessing no. Thoughs? Comments? Gary div Original message /divdivFrom: Benedikt Ritter brit...@apache.org /divdivDate:05/02/2014 13:00 (GMT-05:00) /divdivTo: Commons Developers List dev@commons.apache.org /divdivSubject: Re: [csv] Release planning for commons-csv /divdiv /divSo you're saying we should release 1.0 from the current trunk? I would volunteer to RM. 2014-05-02 16:02 GMT+02:00 Gary Gregory garydgreg...@gmail.com: +1 to keep the discussion going with or without patches. We need to get a 1.0 out the door. Gary On Fri, May 2, 2014 at 4:57 AM, Gabriel Reid gabriel.r...@gmail.com wrote: Hi Benedikt, Thanks for the feedback. My comments are inlined below. On Fri, May 2, 2014 at 9:41 AM, Benedikt Ritter brit...@apache.org wrote: 2014-05-02 8:15 GMT+02:00 Gabriel Reid gabriel.r...@gmail.com: If there are open issues that are specifically standing in the way of a release, I would be happy to assist in attempting to resolve them if someone can point me in the right direction. we are close to a release for a long time now. However we are still looking for a solution to CSV-35 [1] and CSV-58 [2]. There have been long discussions around this issues and to me it looks like there still is no solution. If you have a smart idea feel free to create a patch. Thanks for pointing these out. I'll certainly take a look at them in greater detail to see if there's anything I can see or think of. At commons we are crazy about binary compatibility ;-) We're going through a lot a trouble to make sure you won't run into jar hell when using our components. This is why you can use commons lang 2.6 alongside commons lang 3.3.2 in the same class path. To achieve this, we change the maven coordinates as well as the package coordinates when we break binary compatibility. [snip] The problem is, even if we declare this release as an alpha release or what ever, people will start using it. And all of a sudden you have commons-csv 0.1 in your class path through transitive dependencies but you really need 1.0 which isn't compatible. You're app has been broken by a rushed out release with an unstable API... Understood, and I certainly think that worry about binary compatibility is a worthy cause (and certainly don't want to try to convince the project to go against that principle). However, I think that there are some additional things to consider here as well. Both of the blocking issues are over two years old, with very little activity in the past 6 months. There are currently people making use of commons-csv by doing things like copying the code into their own repo, or making their own release build. These are the same users who are intended to be protected by the promise of binary compatibility, but they (and projects that make use of their published artifacts) will suffer from the same consequences that you outlined by breaking binary incompatibility. The argument could of course be made that people shouldn't be doing things like making their own build or folding the commons-csv code into their own projects, but the fact is that people are doing this (just like people will use a 0.1 release, despite any kinds of warnings about possible future incompatibilites). Additionally, the two issues in question are both classified as bugs, and it appears that both will (or at least could be) eventually be resolved by adding additional configuration methods. This addition of additional configuration methods won't break backwards compatibility. Basically my points are: * by delaying a release to protect users, the same users are doing things which bring the same (or even worse) risks that the delayed release is supposed to be protecting them from * it appears to be possible to resolve the two blocking issues in the future without breaking binary compatibility - Gabriel - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/
Re: [Math] Javadoc with Java 8 (Was: svn commit: r1591664 [2/2] - ...)
On 5/2/14, 6:13 AM, Gilles wrote:
On Fri, 02 May 2014 01:48:28 -0700, Phil Steitz wrote:
On 5/1/14, 7:20 PM, Paul Benedict wrote:
Phil, I don't know who was telling people Javadoc is XML. I
never heard of
that.
Well, could be just be personal ignorance, but the practice of
closing tags in commons javadoc goes back to at least 2002. You can
see it in the [lang] Developer Guide (closing p/'s are referenced
there) and throughout Commons components. I could not find much in
the archives actually discussing it. I vaguely recall some argument
that valid XML would be easier to process with tools other than the
javadoc tool itself. Personally, I find it a little more readable.
I honestly don't care, but do find it irritating that we are being
forced to fiddle with this stuff to keep the tool happy / producing
good warnings.
According to
http://docs.oracle.com/javase/8/docs/technotes/guides/javadoc/whatsnew-7.html
the javadoc tool produces HTML 4.01 Transitional (and thus assumes,
but does not check, that the Javadoc fragments are compliant with
that
specification).
It seems that Java 8 goes some way to check for SGML compliance while
not enforcing HTML 4.01 Strict: According to the the W3C validator
service, every paragraph (including the first sentence in Javadoc!),
should be preceded by a p.
SGML compliance requires supporting null end tags[1]:
http://www.webdevout.net/tidings/2006/04/16/the-problem-with-the-net/
which makes _all_ self-closing tags invalid, a.o. p/ and br/.
XML being ubiquitous in the programming world (and somewhat beyond),
it was an understandable mistake that its syntax would be picked up
in preference to this obscure feature of (somewhat obsoleted) SGML.
[Who is using NET in Javadoc? Actually, who has ever used NET?]
In HTML5, the situation becomes more consistent[2]:
1. p/ is still invalid, because a paragraph cannot be empty (i.e.
it must logically contain the sentence that make up the
paragraph).[3]
2. br/ is accepted. But it is recommended only in specific
situations[4]:
http://www.w3.org/TR/2011/WD-html5-author-20110705/the-br-element.html#the-br-element
Unless I'm mistaken, the javadoc tool of Java 8 thus forbids a syntax
that will be valid in HTML5 for the sake of supporting a feature that
will disappear in HTML5!
I'd tentatively conclude that we should use the following syntax:
p
Some documentation. Further details.
/p
p
Some more documentation.
/p
That would make the fragment valid as HTML 4.01 and 5, as well as
XML.
I agree with Gilles though that entities damage readability and
using *more* of them is a step in the wrong direction.
This is what really started me.
Javadoc in itself is not valid HTML: it must be processed by the
javadoc
tool to _produce_ HTML. Hence there is no advantage in creating a
Javadoc
content that is as close as possible to HTML compliance when more
legible
alternatives exist such as {@code a = 0}.
I will -1
commits that rip out MathJax or mangle the embedded TeX (unless and
until someone explains for legitimate reasons why MathJax itself is
a bad idea).
Do you mean that Javadoc 8 requires that
\( a = 0 \)
be written
\( a le; 0 \)
?
I don't know. I just don't want to have to mangle or rip out the TeX.
Regards,
Gilles
[1] It looks like the existence of this SGML feature is a remnant
from
an epoch where every byte of storage mattered.
And dropping it in XML seemed quite sensible; thus increasing the
consistency and legibility of the notation, and allowing an
obvious
shortcut (the self-closing tag) for empty elements.
[2] Do we agree that HTML5 _is_ the future of HTML? Is Javadoc going
to stick with SGML/HTML4.01?
[3] p is routinely, but wrongly, used (in CM's Javadoc) as a
_separator_.
[4] The way I used br in CM's Javadoc would probably fall in the
not
recommended category.
Not sure I get [3] and [4]. I agree with you that
pBeautiful prose /p
makes sense as the generic paragraph format. Most browsers render
pBeautiful br/
prose /p
with less of a break than
pBeautiful /p
pProse/p
and there are places where our generated javadoc is clearer (IMO)
due to having used the former [5]. Maybe what I am missing is that
the right usage is br instead of br/. The latter, I vaguely
recall starting to use around the same time we started adding /p's
everywhere to make valid XML.
Phil
[5] Here is an example:
http://s.apache.org/z9Q
-
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
[continuum] BUILD FAILURE: Apache Commons JCS - Apache Commons ()
Online report : https://continuum-ci.apache.org/continuum/buildResult.action?buildId=30089projectId=286 Build statistics: State: Failed Previous State: Failed Started at: Fri 2 May 2014 21:00:08 + Finished at: Fri 2 May 2014 21:04:17 + Total time: 4m 8s Build Trigger: Schedule Build Number: 1 Exit code: 1 Building machine hostname: continuum-vm Operating system : Linux(unknown) Java Home version : java version 1.7.0_25 OpenJDK Runtime Environment (IcedTea 2.3.10) (7u25-2.3.10-1ubuntu0.12.04.2) OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode) Builder version : Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 13:51:28+) Maven home: /opt/apache-maven-3.0.5 Java version: 1.7.0_25, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux, version: 3.2.0-53-generic, arch: amd64, family: unix SCM Changes: Changed: tv @ Fri 2 May 2014 20:27:57 + Comment: Simplify and generify statistics Files changed: /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/disk/AbstractDiskCache.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/disk/block/BlockDiskCache.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/disk/indexed/IndexedDiskCache.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/disk/jdbc/JDBCDiskCache.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/lateral/LateralCacheNoWait.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/lateral/LateralCacheNoWaitFacade.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/lateral/socket/tcp/LateralTCPCacheFactory.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/remote/AbstractRemoteAuxiliaryCache.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/remote/AbstractRemoteCacheNoWaitFacade.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/remote/RemoteCache.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/remote/RemoteCacheNoWait.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/CacheEventQueue.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/PooledCacheEventQueue.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/control/CompositeCache.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/AbstractDoubleLinkedListMemoryCache.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/lru/LHMLRUMemoryCache.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/stats/CacheStats.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/stats/StatElement.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/stats/Stats.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/stats/behavior/ICacheStats.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/stats/behavior/IStatElement.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/stats/behavior/IStats.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/utils/struct/LRUMap.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/test/java/org/apache/commons/jcs/JCSThrashTest.java ( 1592029 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean test Arguments: --batch-mode
[continuum] BUILD FAILURE: Apache Commons JCS - Apache Commons (Group (shared) Maven 3 Build Definition (Java 1.6))
Online report : https://continuum-ci.apache.org/continuum/buildResult.action?buildId=30092projectId=286 Build statistics: State: Failed Previous State: Failed Started at: Fri 2 May 2014 21:20:33 + Finished at: Fri 2 May 2014 21:24:02 + Total time: 3m 29s Build Trigger: Schedule Build Number: 1 Exit code: 1 Building machine hostname: continuum-vm Operating system : Linux(unknown) Java Home version : java version 1.6.0_27 OpenJDK Runtime Environment (IcedTea6 1.12.6) (6b27-1.12.6-1ubuntu0.12.04.4) OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode) Builder version : Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 13:51:28+) Maven home: /opt/apache-maven-3.0.5 Java version: 1.6.0_27, vendor: Sun Microsystems Inc. Java home: /usr/lib/jvm/java-6-openjdk-amd64/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux, version: 3.2.0-53-generic, arch: amd64, family: unix SCM Changes: Changed: tv @ Fri 2 May 2014 20:27:57 + Comment: Simplify and generify statistics Files changed: /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/disk/AbstractDiskCache.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/disk/block/BlockDiskCache.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/disk/indexed/IndexedDiskCache.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/disk/jdbc/JDBCDiskCache.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/lateral/LateralCacheNoWait.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/lateral/LateralCacheNoWaitFacade.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/lateral/socket/tcp/LateralTCPCacheFactory.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/remote/AbstractRemoteAuxiliaryCache.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/remote/AbstractRemoteCacheNoWaitFacade.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/remote/RemoteCache.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/remote/RemoteCacheNoWait.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/CacheEventQueue.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/PooledCacheEventQueue.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/control/CompositeCache.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/AbstractDoubleLinkedListMemoryCache.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/lru/LHMLRUMemoryCache.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/stats/CacheStats.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/stats/StatElement.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/stats/Stats.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/stats/behavior/ICacheStats.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/stats/behavior/IStatElement.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/stats/behavior/IStats.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/utils/struct/LRUMap.java ( 1592029 ) /commons/proper/jcs/trunk/commons-jcs-core/src/test/java/org/apache/commons/jcs/JCSThrashTest.java ( 1592029 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode
Re: [VFS] JDK 8 2.1-SNAPSHOT
Hello, I opened VFS-521 for this, and it looks like the problem is in try-with-resource in Java8 FilterOutputStream. The test in question is expected to fail with an IOException. Gruss Bernd Am Fri, 02 May 2014 12:27:01 +0100 schrieb Schalk Cronjé ysb...@gmail.com: Does anyone else have failures building VFS 2.1 with JDK8 (SVN rev 1591869)? I am seeing this test failure building on Mac. --- Test set: org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest --- Tests run: 9, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.012 sec FAILURE! - in org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest testSmallFS(org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest) Time elapsed: 0.007 sec ERROR! java.lang.IllegalArgumentException: Self-suppression not permitted at org.apache.commons.vfs2.provider.ram.RamFileObject.resize(RamFileObject.java:277) at org.apache.commons.vfs2.provider.ram.RamFileOutputStream.write(RamFileOutputStream.java:68) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) at org.apache.commons.vfs2.util.MonitorOutputStream.flush(MonitorOutputStream.java:114) at java.io.FilterOutputStream.close(FilterOutputStream.java:158) at org.apache.commons.vfs2.util.MonitorOutputStream.close(MonitorOutputStream.java:54) at org.apache.commons.vfs2.provider.DefaultFileContent$FileContentOutputStream.close(DefaultFileContent.java:711) at org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest.testSmallFS(CustomRamProviderTest.java:264) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SANDBOX][BEANUTILS2] Changing code style
+1 I don't like the curly brace on new line rule as it wastes vertical space ! On 2 May 2014 14:57, Gary Gregory garydgreg...@gmail.com wrote: +1 Gary On Fri, May 2, 2014 at 6:53 AM, Benedikt Ritter brit...@apache.org wrote: Hi all, BeanUtils2 uses the maven code style rules. Every now and then I have to reject patches because they don't follow these conventions. I'd like to change the formatting rules to a more standard rule set for the following reasons: - maven style is very verbose, since it uses a lot of spaces and curly braces have to be placed on new lines - a great majority of our components uses the Sun/Eclipse formatting with spaces - Setting up IDEs like IntelliJ or Eclipse is easier with the Sun/Eclipse style, because the only thing you have to change is the tab policy. Using the maven style implies that one has to import the rule set. If no one objects, I'll reformat the source code and update the check style rules. Regards, Benedikt -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[dbcp] cutting 2.0.1
DBCP-414 is kind of nasty so it would be good to cut a patch release including the fix for it. A couple of other issues have also been resolved since the release of 2.0. I will volunteer to RM. Unless I hear objections, I will start cutting RMs in in the next couple of days based on the code in trunk. Review of the fixes for DBCP-412 and DBCP-417 would be appreciated. Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SANDBOX][BEANUTILS2] Changing code style
Hi, Eclipse style seems to be better :) Regards, -Yogesh On Sat, May 3, 2014 at 7:42 AM, sebb seb...@gmail.com wrote: +1 I don't like the curly brace on new line rule as it wastes vertical space ! On 2 May 2014 14:57, Gary Gregory garydgreg...@gmail.com wrote: +1 Gary On Fri, May 2, 2014 at 6:53 AM, Benedikt Ritter brit...@apache.org wrote: Hi all, BeanUtils2 uses the maven code style rules. Every now and then I have to reject patches because they don't follow these conventions. I'd like to change the formatting rules to a more standard rule set for the following reasons: - maven style is very verbose, since it uses a lot of spaces and curly braces have to be placed on new lines - a great majority of our components uses the Sun/Eclipse formatting with spaces - Setting up IDEs like IntelliJ or Eclipse is easier with the Sun/Eclipse style, because the only thing you have to change is the tab policy. Using the maven style implies that one has to import the rule set. If no one objects, I'll reformat the source code and update the check style rules. Regards, Benedikt -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
