Re: [VOTE] Release commons-io 2.5 based on RC1
I had the same maven errors while working on IO-487, but I assumed it was because my local copy was not set up correctly. The TailerTest fails intermittently with or without Cobertura. Adrian Crum Sandglass Software www.sandglass-software.com On 11/24/2015 5:36 PM, Gary Gregory wrote: Just to add to Java 8 woes, running "mvn clean site", I get: [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 08:01 min [INFO] Finished at: 2015-11-24T16:13:48-08:00 [INFO] Final Memory: 62M/540M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on project commons-io: Execution default-site of goal org.apache.maven.plugins:maven-site-plugin:3.4:site failed: Invalid byte tag in constant pool: 15 -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException Using: Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00) Maven home: E:\Java\apache-maven-3.3.9\bin\.. Java version: 1.8.0_65, vendor: Oracle Corporation Java home: C:\Program Files\Java\jdk1.8.0_65\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos" It probably has nothing to do with us, just a data point. This is from the src zip, ASC, MD5, SHA1, and reports are OK. I can build with "mvn clean site" OK with: Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00) Maven home: E:\Java\apache-maven-3.3.9\bin\.. Java version: 1.7.0_79, vendor: Oracle Corporation Java home: C:\Program Files\Java\jdk1.7.0_79\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" So +1 from me based on my experience. I am worried about the report failures on the VOTE thread though. I did not install/run with Java 6 though. Caveat, while in the Cobertura part of the build, I saw this: Tests run: 10, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 26.076 sec <<< FAILURE! - in org.apache.commons.io.input.TailerTest testTailer(org.apache.commons.io.input.TailerTest) Time elapsed: 5.412 sec <<< FAILURE! junit.framework.AssertionFailedError: Missing InterruptedException at junit.framework.Assert.fail(Assert.java:57) at junit.framework.Assert.assertTrue(Assert.java:22) at junit.framework.Assert.assertNotNull(Assert.java:256) at junit.framework.TestCase.assertNotNull(TestCase.java:426) at org.apache.commons.io.input.TailerTest.testTailer(TailerTest.java:258) But I did not see the above during the normal test phase of the build. Gary On Tue, Nov 24, 2015 at 12:59 PM, Oliver Heger <oliver.he...@oliver-heger.de wrote: Hi Kristian, while checking the release I found some problems: * The commons-io-2.5.jar in the binary distribution contains a cobertura.properties file. This is probably created by running the site build over the release build before creating the distributions. In the past we had a problematic release because Cobertura seems to mess up some classes. I cannot remember the exact details, but the jar was not working correctly. Could this be the case here, too? * The copyright year in NOTICE is still 2014. I think this is blocking. * Building with Java 1.6 on Windows 10 gives a test failure: --- Test set: org.apache.commons.io.FileUtilsTestCase --- Tests run: 134, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.203 sec <<< FAILURE! - in org.apache.commons.io.FileUtilsTestCase testGetFile(org.apache.commons.io.FileUtilsTestCase) Time elapsed: 0 sec <<< ERROR! java.io.IOException: Cannot create file C:\data\dev\projects\OpenSource\io\commons-io-2.5-src\test\io\file1-test.txt as the parent directory does not exist at org.apache.commons.io.testtools.FileBasedTestCase.createFile(FileBasedTestCase.java:60) at org.apache.commons.io.FileUtilsTestCase.setUp(FileUtilsTestCase.java:101) With Java 1.8 it is worse; here I get 71 errors which are mostly similar to the one before (all in FileUtilsTestCase). The site looks okay except for the JIRA report which is missing. -1 Sorry Oliver Am 23.11.2015 um 18:31 schrieb Kr
Re: [VOTE] Release Validator 1.5.0 based on RC1
On 11/19/2015 1:09 PM, Oliver Heger wrote: * I wanted to test the ant build, but it seemed pretty difficult to come to a working setup based on the sample properties. There are components that ship sample properties which reference the local Maven repo and are much easier to use. Maybe drop the ant build completely? I have the same problem with a number of Commons projects. I prefer to use ant (since Commons poms are huge black boxes), but the ant builds aren't kept current. I agree the ant build files should be dropped if no one is willing to maintain them. Adrian Crum Sandglass Software www.sandglass-software.com - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [validator] Inconsistent behavior in UrlValidator
The address range 127.0.0.0 to 127.255.255.255 is reserved for loopback testing. It seems pretty straightforward to me. Adrian Crum Sandglass Software www.sandglass-software.com On 9/27/2015 8:07 AM, Kristian Rosenvold wrote: 127.0.0.1 is not always the address for localhost. This is a can of worms big enough to drive a medium-sized container ship into Kristian 27. sep. 2015 4.13 p.m. skrev "Benedikt Ritter" <brit...@apache.org>: Hm... since localhost is usually only an alias for 127.0.0.1 it doesn't really make sense to allow one but not the other. 2015-09-25 23:18 GMT+02:00 Adrian Crum <adrian.c...@sandglass-software.com : I was just looking at the UrlValidator test and I noticed that localhost is allowed in the URL if the ALLOW_LOCAL_URLS flag is set, and it is not allowed if the ALLOW_LOCAL_URLS flag is not set. If the ALLOW_LOCAL_URLS is not set, a loopback IP address (127.0.0.1) URL will validate. It seems to me that it shouldn't - to be consistent with the localhost behavior. What do you think? -- Adrian Crum Sandglass Software www.sandglass-software.com - 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[validator] Inconsistent behavior in UrlValidator
I was just looking at the UrlValidator test and I noticed that localhost is allowed in the URL if the ALLOW_LOCAL_URLS flag is set, and it is not allowed if the ALLOW_LOCAL_URLS flag is not set. If the ALLOW_LOCAL_URLS is not set, a loopback IP address (127.0.0.1) URL will validate. It seems to me that it shouldn't - to be consistent with the localhost behavior. What do you think? -- Adrian Crum Sandglass Software www.sandglass-software.com - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: need some help
or Commons-Convert. Adrian Crum Sandglass Software www.sandglass-software.com On 9/2/2015 12:53 PM, Gary Gregory wrote: You can also look at incubating projects like Commons-RDF. Gary On Wed, Sep 2, 2015 at 12:39 PM, Arsen Babakhanyan <arsen...@gmail.com> wrote: My problem that i am currently trying to figure out is to find a project or component that is not in a final or stabile state, so it will be interesting to join it in this point. There are a lot of already stabile projects, components where good and interesting things are already done. Of course being good, interesting, final, stabile are all relative things, but i hope you understand my point. But yes going with commit history is one possible solution. Thanks ! On Wed, Sep 2, 2015 at 11:31 PM, Benedikt Ritter <benerit...@gmail.com> wrote: Hello Arsen, you can get an idea about what projects are currently been worked on by looking into the SVN/git commit history. We have some projects which are maintained more frequently like Commons Lang, Commons Net, Commons VFS and the like. You should just dig into the projekt you're interested the most and start to work on that one bei discussing changes here on the development list or contributing improvements/fixes via jira or github. HTH, Benedikt 2015-09-02 17:10 GMT+02:00 Arsen Babakhanyan <arsen...@gmail.com>: Hi everybody, I am interested in participating in some projects, but need some help. I don't know how to find currently active projects that are in development or a project that needs help at all and the second problem help with getting started as i am new here. (going to be :) ) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Git] drop SVN repos for components using Git?
Do the Git repos include the Subversion commit history? Adrian Crum Sandglass Software www.sandglass-software.com On 5/8/2015 8:53 AM, sebb wrote: Is there any point in keeping the SVN repos for components that have moved to Git? They are read-only (or should be) and are not synchronised with the Git repo, so they can be confusing. If there is a need to keep them, they should be renamed so people cannot accidentally use them. It might be an idea to keep just a README file pointing to the Git repo, but I think the contents should be dropped, or perhaps moved under commons/Git, at least temporarily. - 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: org.apache.commons.lang3.SystemUtils.IS_OS_WINDOWS_8_1
I can do that. Adrian Crum Sandglass Software www.sandglass-software.com On 4/25/2015 9:56 AM, Gary Gregory wrote: Is there anyone with a Windows 8.1 system available to implement and test a new method org.apache.commons.lang3.SystemUtils.IS_OS_WINDOWS_8_1? Thank you, Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collections] Revert a performance related fix in 4.1
Slightly off-topic but somewhat related... I saw a recent commit where a performance improvement went something like this: StringBuilder sb = new StringBuilder(); sb.append(foo); was replaced with StringBuilder sb = new StringBuilder(foo); The change reduced the code by one line, but there was no performance improvement - because the StringBuilder constructor calls append(). So, I agree that suggested performance improvements should be met with a great deal of skepticism and they should be closely scrutinized. Adrian Crum Sandglass Software www.sandglass-software.com On 1/24/2015 10:21 AM, Thomas Neidhart wrote: Hi, from time to time some researchers trying to find performance bugs in open-source software create issues for collections. One of the easy targets is the Collection#retainAll(Collection) method as the default implementation in AbstractCollection calls contains on the provided collection. Now, in the worst-case this may lead to a runtime complexity of O(n^2), i.e. when the collection has a contains implementation with O(n) complexity. The proposed solution is usually to create an intermediate set and use it to speed up the contains calls. My position was always that a given Collection class shall not overwrite this method trying to optimize its runtime behavior for any possible input by creating such intermediate data structures as this will just increase the space complexity (in many cases unnecessarily). Instead, the runtime complexity was documented (one can even question this as the Collection framework should be well-known by java users). It looks like that at 2 occasions these performance bugs got fixed: * https://issues.apache.org/jira/browse/COLLECTIONS-426 * https://issues.apache.org/jira/browse/COLLECTIONS-427 and I would like to revert these fixes as they are wrong imho and just create a precedent for further tickets. Does anybody challenge my rationale behind this or can I go ahead with it? 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: Commons Dev List Activity Levels
You can set up your email client to filter out messages you are not interested in. Adrian Crum Sandglass Software www.sandglass-software.com On 1/6/2015 3:37 PM, Christopher wrote: Hi, With the recent announcement about commits to commons being opened up, I joined the dev@commons.apache.org list to follow the activity, for my own curiosity, and to seek out opportunities for participation and mutual interests. However, I've been a bit overwhelmed by the activity on the list, from concurrent votes for releases on sub-projects, to automated notifications from Wiki and GitHub pull requests, to ongoing discussions about switching to git, plus a myriad of other threads. So, I was wondering a few things: 1) Is this considered normal activity for this list? 2) How do people deal with this level of activity? Does anybody have any suggestions to a newcomer / lurker? 3) Is there any interest in removing some of the automated notifications (or moving them to a notifications list)? If so, which types are ideal candidates? -- Christopher L Tubbs II http://gravatar.com/ctubbsii - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1649038 - /commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/InetAddressValidator.java
Thank you for fixing that. I had my IDE set for Java 1.4 but somehow it
let me use that method anyway.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/2/2015 6:17 AM, s...@apache.org wrote:
Author: sebb
Date: Fri Jan 2 14:17:48 2015
New Revision: 1649038
URL: http://svn.apache.org/r1649038
Log:
https://issues.apache.org/jira/browse/VALIDATOR-307
Replace String.isEmpty() with Java 1.4 compatible code
Modified:
commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/InetAddressValidator.java
Modified:
commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/InetAddressValidator.java
URL:
http://svn.apache.org/viewvc/commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/InetAddressValidator.java?rev=1649038r1=1649037r2=1649038view=diff
==
---
commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/InetAddressValidator.java
(original)
+++
commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/InetAddressValidator.java
Fri Jan 2 14:17:48 2015
@@ -82,7 +82,7 @@ public class InetAddressValidator implem
// verify that address subgroups are legal
for (int i = 0; i = 3; i++) {
String ipSegment = groups[i];
-if (ipSegment == null || ipSegment.isEmpty()) {
+if (ipSegment == null || ipSegment.length() == 0) {
return false;
}
@@ -139,7 +139,7 @@ public class InetAddressValidator implem
int emptyOctets = 0;
for (int index = 0; index octets.length; index++) {
String octet = (String) octets[index];
-if (octet.isEmpty()) {
+if (octet.length() == 0) {
emptyOctets++;
if (emptyOctets 1) {
return false;
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1648642 - /commons/proper/validator/trunk/src/test/java/org/apache/commons/validator/routines/DomainValidatorTest.java
Be aware that the file contains encoded Chinese TLDs (XN--*). So, it
needs additional parsing.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 12/30/2014 5:23 PM, s...@apache.org wrote:
Author: sebb
Date: Wed Dec 31 01:23:26 2014
New Revision: 1648642
URL: http://svn.apache.org/r1648642
Log:
Add code for developers to check inbuilt list against iana tld
Modified:
commons/proper/validator/trunk/src/test/java/org/apache/commons/validator/routines/DomainValidatorTest.java
Modified:
commons/proper/validator/trunk/src/test/java/org/apache/commons/validator/routines/DomainValidatorTest.java
URL:
http://svn.apache.org/viewvc/commons/proper/validator/trunk/src/test/java/org/apache/commons/validator/routines/DomainValidatorTest.java?rev=1648642r1=1648641r2=1648642view=diff
==
---
commons/proper/validator/trunk/src/test/java/org/apache/commons/validator/routines/DomainValidatorTest.java
(original)
+++
commons/proper/validator/trunk/src/test/java/org/apache/commons/validator/routines/DomainValidatorTest.java
Wed Dec 31 01:23:26 2014
@@ -16,6 +16,15 @@
*/
package org.apache.commons.validator.routines;
+import java.io.BufferedReader;
+import java.io.File;
+import java.io.FileOutputStream;
+import java.io.FileReader;
+import java.io.InputStream;
+import java.net.HttpURLConnection;
+import java.net.URL;
+import java.util.Locale;
+
import junit.framework.TestCase;
/**
@@ -110,4 +119,37 @@ public class DomainValidatorTest extends
public void testIDN() {
assertTrue(b\u00fccher.ch in IDN should validate,
validator.isValid(www.xn--bcher-kva.ch));
}
+
+// Download and process local copy of
http://data.iana.org/TLD/tlds-alpha-by-domain.txt
+// Check if the internal TLD table is up to date
+public static void main(String a[]) throws Exception {
+DomainValidator dv = DomainValidator.getInstance();;
+File f = new File(target/tlds-alpha-by-domain.txt);
+if (!f.canRead()) {
+String tldurl=http://data.iana.org/TLD/tlds-alpha-by-domain.txt;;
+System.out.println(Downloading + tldurl);
+byte buff[] = new byte[1024];
+HttpURLConnection hc = (HttpURLConnection) new
URL(tldurl).openConnection();
+InputStream is = hc.getInputStream();
+FileOutputStream fos = new FileOutputStream(f);
+while(is.read(buff) != -1) {
+fos.write(buff);
+}
+fos.close();
+is.close();
+System.out.println(Done);
+}
+BufferedReader br = new BufferedReader(new FileReader(f));
+System.out.println(Entries missing from TLD List);
+String line;
+while((line = br.readLine()) != null) {
+if (!line.startsWith(#)) {
+if (!dv.isValidTld(line)) {
+System.out.println(line.toLowerCase(Locale.ENGLISH));
+}
+}
+}
+br.close();
+System.out.println(Done);
+}
}
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Validator 1.4.1 based on RC1
It would be nice if the maintenance release included this fix: https://issues.apache.org/jira/browse/VALIDATOR-307 I was planning on working on it this weekend. Adrian Crum Sandglass Software www.sandglass-software.com On 12/26/2014 3:00 PM, Benedikt Ritter wrote: Hello, We have received some requests to release the fixes we habe implemented in Commons Validator since 1.4 was released, so I would like to release Validator 1.4.1. Validator 1.4.1 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/validator/ (svn revision 7587) Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1071/commons-validator/commons-validator/1.4.1/ Details of changes since 1.4 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/validator/RELEASE-NOTES.txt I have tested this with JDK 1.6, 1.7, 1.8 and 1.9 EA using maven 3.2.5. Note that the build doesn't work with JDK 1.9 EA, since source and target option 1.4 have been removed in JDK 1.9. The tag is here: http://svn.apache.org/repos/asf/commons/proper/validator/tags/VALIDATOR_1_4_1_RC1/ (svn revision 1647978) Site: no site - I'm currently having trouble to login to people.apache.org, so I was unable to upload the site. Please build the site yourself using mvn clean site. Clirr Report (compared to 1.1): see above RAT Report: see above KEYS: https://www.apache.org/dist/commons/KEYS Please review the release candidate and vote. This vote will close no sooner that 72 hours from now, i.e. after 2014/12/29 16:00 CET [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Thanks! Benedikt - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ANNOUNCEMENT] Apache Commons grants write access to all ASF committers
The challenge will be to keep Jira up-to-date. I would like to wrap up some Jira issues too, but ASF committers do not have edit permissions in Commons Jira. Adrian Crum Sandglass Software www.sandglass-software.com On 12/18/2014 2:42 AM, Carl Hall wrote: Very cool! I've been digging through the JIRA tickets for dbutils. I would like to help clear those out and add some new things to the library. I'll be sure to send details to the list as things come up. On Mon, Dec 15, 2014 at 8:05 AM, Benedikt Ritter brit...@apache.org wrote: Dear fellow committers, The Apache Commons Team is pleased to announce that write access to the Apache Commons Subversion and Git repositories has been granted to all ASF committers. Apache Commons is an Apache project focused on all aspects of reusable Java components. As such, the components maintained by the Apache Commons project may be of interest to a variety of other Apache projects. The Apache Commons community would like to invite you to share and maintain useful code. While Apache Commons is a Commit-Then-Review community, we would consider it polite and helpful for contributors to announce their intentions and plans on the dev mailing list [1] before committing code. Have fun, Benedikt Ritter, on behalf of the Apache Commons Community [1] http://commons.apache.org/mail-lists.html -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1635052 - in /commons/proper/csv/trunk/src: changes/ main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Generally speaking, good designs are not based on class count.
If we simply add methods to the parser every time a user comes up with a
new use case, then eventually we will end up with a single class that
tries to be all things to all people.
The decorator pattern is ideally suited for situations like this:
1. I need a basic CSV parser: Use the basic parser.
2. I need a CSV parser that supports random access: Use basic parser
decorated by Random Access decorator.
3. I need a CSV parser that supports foo: Use basic parser decorated by
Foo decorator.
4. I need...
From my perspective, that makes client code cleaner and simpler, not
more complicated.
But like many design discussions, that is a personal preference and
others may feel differently.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 10/29/2014 4:08 PM, Gary Gregory wrote:
On Wed, Oct 29, 2014 at 4:13 AM, Benedikt Ritter brit...@apache.org wrote:
Hi Gary,
what do you think about the Decorator approach, suggested by Adrian Crum in
JIRA?
In theory, it's OK, but in this specific case, it does not seem to me worth
the cost (an extra class) and complexity (it makes the client code more
complicated). It is also not clear that it would be easy to do based on the
other comments in the JIRA. I do not plan on researching this path but I
suppose I would examine a patch.
Gary
Benedikt
2014-10-29 6:44 GMT+01:00 ggreg...@apache.org:
Author: ggregory
Date: Wed Oct 29 05:44:40 2014
New Revision: 1635052
URL: http://svn.apache.org/r1635052
Log:
[CSV-131] Save positions of records to enable random access. The floor is
open for code review and further discussion based on the comments in the
Jira.
Modified:
commons/proper/csv/trunk/src/changes/changes.xml
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVParser.java
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVRecord.java
commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVParserTest.java
commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVRecordTest.java
Modified: commons/proper/csv/trunk/src/changes/changes.xml
URL:
http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/changes/changes.xml?rev=1635052r1=1635051r2=1635052view=diff
==
--- commons/proper/csv/trunk/src/changes/changes.xml (original)
+++ commons/proper/csv/trunk/src/changes/changes.xml Wed Oct 29 05:44:40
2014
@@ -39,6 +39,7 @@
/properties
body
release version=1.1 date=2014-mm-dd description=Feature and
bug
fix release
+ action issue=CSV-131 type=add dev=ggregory due-to=Holger
StratmannSave positions of records to enable random access/action
action issue=CSV-130 type=fix dev=ggregory due-to=Sergei
LebedevCSVFormat#withHeader doesn't work well with #printComment, add
withHeaderComments(String...)/action
action issue=CSV-128 type=fix dev=ggregoryCSVFormat.EXCEL
should ignore empty header names/action
action issue=CSV-129 type=add dev=ggregoryAdd
CSVFormat#with 0-arg methods matching boolean arg methods/action
Modified:
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVParser.java
URL:
http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVParser.java?rev=1635052r1=1635051r2=1635052view=diff
==
---
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVParser.java
(original)
+++
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVParser.java
Wed Oct 29 05:44:40 2014
@@ -219,6 +219,12 @@ public final class CSVParser implements
private final ListString record = new ArrayListString();
private long recordNumber;
+
+/**
+ * Lexer offset if the parser does not start parsing at the
beginning
of the source. Usually used in combination
+ * with {@link #setNextRecordNumber(long)}
+ */
+private long characterOffset;
private final Token reusableToken = new Token();
@@ -296,6 +302,43 @@ public final class CSVParser implements
}
/**
+ * Sets the record number to be assigned to the next record read.
+ * p
+ * Use this if the reader is not positioned at the first record when
you create the parser. For example, the first
+ * record read might be the 51st record in the source file.
+ * /p
+ * p
+ * If you want the records to also have the correct character
position referring to the underlying source, call
+ * {@link #setNextCharacterPosition(long)}.
+ * /p
+ *
+ * @param nextRecordNumber
+ *the next record number
+ * @since 1.1
+ */
+public void setNextRecordNumber(long nextRecordNumber) {
+this.recordNumber = nextRecordNumber - 1;
+}
+
+/**
+ * Sets the current position in the source stream regardless
Re: svn commit: r1635052 - in /commons/proper/csv/trunk/src: changes/ main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Writing code before agreeing on a design is putting the cart before the horse. If there is immediate push-back on a design, then why would anyone want to write the code for it? I don't see how HttpComponents is relevant. So what if they deprecated their decorators? Oracle continues marching on with in/out stream decorators, reader/writer decorators... A Reader should be something simple to use, it's just a means to read characters. If I want to add buffering, I decorate it with BufferedReader. If I want to add line numbering, I decorate it with LineNumberReader. If I want to add... The Java API includes those classes as a convenience - and we are talking about something even more low-level than CSV file parsing. The decorator pattern exists for a reason - and the Java IO classes are a perfect application of it. I can't imagine a closer parallel to this discussion. Adrian Crum Sandglass Software www.sandglass-software.com On 10/29/2014 5:01 PM, Gary Gregory wrote: This should be something simple to use, it's just a parser for a 'simple' file format. I get a format, a parser and my data. If each new feature is a decorator I'm going to end up creating 5 classes to use 5 features, no thanks. Like you said, it could be a matter of personal taste. Over at HttpComponents HttpClient, the decorators have been deprecated in favor of builders. Here at CSV, we have a builder for CSV formats. So maybe that should be used, at least it would be consistent. Also, until someone tries to create a decorator, it's just talk, and from one of the comments, it might not be doable... Gary On Wed, Oct 29, 2014 at 12:39 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: Generally speaking, good designs are not based on class count. If we simply add methods to the parser every time a user comes up with a new use case, then eventually we will end up with a single class that tries to be all things to all people. The decorator pattern is ideally suited for situations like this: 1. I need a basic CSV parser: Use the basic parser. 2. I need a CSV parser that supports random access: Use basic parser decorated by Random Access decorator. 3. I need a CSV parser that supports foo: Use basic parser decorated by Foo decorator. 4. I need... From my perspective, that makes client code cleaner and simpler, not more complicated. But like many design discussions, that is a personal preference and others may feel differently. Adrian Crum Sandglass Software www.sandglass-software.com On 10/29/2014 4:08 PM, Gary Gregory wrote: On Wed, Oct 29, 2014 at 4:13 AM, Benedikt Ritter brit...@apache.org wrote: Hi Gary, what do you think about the Decorator approach, suggested by Adrian Crum in JIRA? In theory, it's OK, but in this specific case, it does not seem to me worth the cost (an extra class) and complexity (it makes the client code more complicated). It is also not clear that it would be easy to do based on the other comments in the JIRA. I do not plan on researching this path but I suppose I would examine a patch. Gary Benedikt 2014-10-29 6:44 GMT+01:00 ggreg...@apache.org: Author: ggregory Date: Wed Oct 29 05:44:40 2014 New Revision: 1635052 URL: http://svn.apache.org/r1635052 Log: [CSV-131] Save positions of records to enable random access. The floor is open for code review and further discussion based on the comments in the Jira. Modified: commons/proper/csv/trunk/src/changes/changes.xml commons/proper/csv/trunk/src/main/java/org/apache/commons/ csv/CSVParser.java commons/proper/csv/trunk/src/main/java/org/apache/commons/ csv/CSVRecord.java commons/proper/csv/trunk/src/test/java/org/apache/commons/ csv/CSVParserTest.java commons/proper/csv/trunk/src/test/java/org/apache/commons/ csv/CSVRecordTest.java Modified: commons/proper/csv/trunk/src/changes/changes.xml URL: http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/ changes/changes.xml?rev=1635052r1=1635051r2=1635052view=diff == --- commons/proper/csv/trunk/src/changes/changes.xml (original) +++ commons/proper/csv/trunk/src/changes/changes.xml Wed Oct 29 05:44:40 2014 @@ -39,6 +39,7 @@ /properties body release version=1.1 date=2014-mm-dd description=Feature and bug fix release + action issue=CSV-131 type=add dev=ggregory due-to=Holger StratmannSave positions of records to enable random access/action action issue=CSV-130 type=fix dev=ggregory due-to=Sergei LebedevCSVFormat#withHeader doesn't work well with #printComment, add withHeaderComments(String...)/action action issue=CSV-128 type=fix dev=ggregoryCSVFormat.EXCEL should ignore empty header names/action action issue=CSV-129 type=add dev=ggregoryAdd CSVFormat#with 0-arg methods matching boolean arg methods/action Modified: commons/proper/csv/trunk/src/main/java/org/apache/commons/ csv
Re: svn commit: r1632171 [1/20] - in /commons/proper/beanutils/trunk/src: main/java/org/apache/commons/beanutils/ main/java/org/apache/commons/beanutils/converters/ main/java/org/apache/commons/beanut
From my perspective, the final keywords don't add anything of value to the library. If their addition to the library makes code maintenance difficult, then it would be best to remove them. Adrian Crum Sandglass Software www.sandglass-software.com On 10/24/2014 9:01 PM, Gary Gregory wrote: On Fri, Oct 24, 2014 at 3:23 PM, Oliver Heger oliver.he...@oliver-heger.de wrote: Am 23.10.2014 um 22:58 schrieb Gary Gregory: Patches go stale no matter what... Right, this can happen during normal development, but not necessarily because of a big bang change for which there is no technical reason, but which is just a matter of personal taste. I call it a technical reason, you call it personal taste, we are not going to agree. Gary Oliver Gary div Original message /divdivFrom: Oliver Heger oliver.he...@oliver-heger.de /divdivDate:10/23/2014 15:34 (GMT-05:00) /divdivTo: dev@commons.apache.org /divdivSubject: Re: svn commit: r1632171 [1/20] - in /commons/proper/beanutils/trunk/src: main/java/org/apache/commons/beanutils/ main/java/org/apache/commons/beanutils/converters/ main/java/org/apache/commons/beanutils/expression/ main/java/org/apache/commons/beanutils/l... /divdiv /divThere was no reaction on my comment so far. I am tempted to -1 this commit. There is already a report about a patch which cannot be applied (comment to [1]). Oliver [1] https://issues.apache.org/jira/browse/BEANUTILS-417 Am 16.10.2014 um 21:22 schrieb Oliver Heger: To be honest, I really don't like this commit. My personal sense for aesthetics put aside, you modified almost the whole code base. Patches assigned to Jira tickets will probably no longer apply cleanly. Oliver Am 15.10.2014 um 22:15 schrieb ggreg...@apache.org: Author: ggregory Date: Wed Oct 15 20:15:17 2014 New Revision: 1632171 URL: http://svn.apache.org/r1632171 Log: Add final modifier to method parameters. Add final modifier to local variables. Modified: commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/BaseDynaBeanMapDecorator.java commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/BasicDynaBean.java commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/BasicDynaClass.java commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/BeanAccessLanguageException.java commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/BeanComparator.java commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/BeanIntrospectionData.java commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/BeanMap.java commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/BeanPredicate.java commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/BeanPropertyValueChangeClosure.java commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/BeanPropertyValueEqualsPredicate.java commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/BeanToPropertyValueTransformer.java commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/BeanUtils.java commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/BeanUtilsBean.java commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/BeanUtilsBean2.java commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/ConstructorUtils.java commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/ContextClassLoaderLocal.java commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/ConversionException.java commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/ConvertUtils.java commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/ConvertUtilsBean.java commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/ConvertUtilsBean2.java commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/ConvertingWrapDynaBean.java commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/DefaultBeanIntrospector.java commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/DefaultIntrospectionContext.java commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/DynaBeanMapDecorator.java commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/DynaBeanPropertyMapDecorator.java commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/DynaProperty.java commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/FluentPropertyBeanIntrospector.java commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/JDBCDynaClass.java commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils
Re: [CANCEL][VOTE] Release Commons CSV 1.0 based on RC1
Why would we target Java 5? It is long past end-of-life. Adrian Crum Sandglass Software www.sandglass-software.com On 7/13/2014 10:12 AM, Benedikt Ritter wrote: Hi all, this vote it canceled to address the various issues identified. I'll need some time to work through the list, so I expect the next RC by mid of the week (help is always welcome ;-). Till then I'd like to hear comments regarding the Java version to target. From what I've seen it looks like we can remove all the Java 6/7 stuff and target Java 5. Benedikt 2014-07-11 22:44 GMT+02:00 Benedikt Ritter brit...@apache.org: We have worked a long time on CSV and more an more people seem to be using the SNAPSHOT since there is no stable release. Although we still have some outstanding issues regarding some corner cases and uncommon formats, It feels like the API as reached a solid state. So I'd like to finally release CSV 1.0. CSV 1.0 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/csv/ (svn rev. 5829) (note that CSV can be build using Java 8.0, but the website cannot, since the maven-findbugs-plugin is still uncompatible with Java 8.0) Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1039 Details of changes since we started with 1.0 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/csv/RELEASE-NOTES.txt http://people.apache.org/~britter/csv-1.0-RC1/changes-report.html The tag is here: http://svn.apache.org/repos/asf/commons/proper/csv/tags/CSV_1.0_RC1/ (svn rev. 1609779) N.B. the SVN revision is required because SVN tags are not immutable. Site: http://people.apache.org/~britter/csv-1.0-RC1/ (note some *relative* links are broken and the 1.0 directories are not yet created - these will be OK once the site is deployed) Clirr Report: -- No Clirr report, since this is the first release -- RAT Report: http://people.apache.org/~britter/csv-1.0-RC1/rat-report.html (note that the files in src/test/resources are ignored by rat, since they are used as test csv input and test result specifications) 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 2300 GMT 14-July 2014 [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Thanks! Benedikt -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CANCEL][VOTE] Release Commons CSV 1.0 based on RC1
I would be inclined to leave Java 5 compatibility to the few (if any) people who still use it. They have access to the CSV source code and they can modify it to make it Java 5 compatible. Adrian Crum Sandglass Software www.sandglass-software.com On 7/13/2014 10:30 AM, Benedikt Ritter wrote: 2014-07-13 11:27 GMT+02:00 Adrian Crum adrian.c...@sandglass-software.com: Why would we target Java 5? It is long past end-of-life. Well I don't have a strong preference here. The reason people bring up for targeting older Java versions is, to reach a broader user group. I'm fine with targeting Java 7. Adrian Crum Sandglass Software www.sandglass-software.com On 7/13/2014 10:12 AM, Benedikt Ritter wrote: Hi all, this vote it canceled to address the various issues identified. I'll need some time to work through the list, so I expect the next RC by mid of the week (help is always welcome ;-). Till then I'd like to hear comments regarding the Java version to target. From what I've seen it looks like we can remove all the Java 6/7 stuff and target Java 5. Benedikt 2014-07-11 22:44 GMT+02:00 Benedikt Ritter brit...@apache.org: We have worked a long time on CSV and more an more people seem to be using the SNAPSHOT since there is no stable release. Although we still have some outstanding issues regarding some corner cases and uncommon formats, It feels like the API as reached a solid state. So I'd like to finally release CSV 1.0. CSV 1.0 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/csv/ (svn rev. 5829) (note that CSV can be build using Java 8.0, but the website cannot, since the maven-findbugs-plugin is still uncompatible with Java 8.0) Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1039 Details of changes since we started with 1.0 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/csv/RELEASE- NOTES.txt http://people.apache.org/~britter/csv-1.0-RC1/changes-report.html The tag is here: http://svn.apache.org/repos/asf/commons/proper/csv/tags/ CSV_1.0_RC1/ (svn rev. 1609779) N.B. the SVN revision is required because SVN tags are not immutable. Site: http://people.apache.org/~britter/csv-1.0-RC1/ (note some *relative* links are broken and the 1.0 directories are not yet created - these will be OK once the site is deployed) Clirr Report: -- No Clirr report, since this is the first release -- RAT Report: http://people.apache.org/~britter/csv-1.0-RC1/rat-report.html (note that the files in src/test/resources are ignored by rat, since they are used as test csv input and test result specifications) 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 2300 GMT 14-July 2014 [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Thanks! Benedikt -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter - 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] Proposed fix for CSV-35 (Was: Fwd: [jira] [Comment Edited] (CSV-35) Escaped line separators are not supported)
I agree that we should stop worrying about edge cases and release a
version that covers the majority of needs.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 7/10/2014 9:12 AM, Benedikt Ritter wrote:
2014-07-09 4:15 GMT+02:00 Gary Gregory garydgreg...@gmail.com:
We do have a discrepancy between our format class and lexer (which is
hardwired with CR LF).
Ideally, it seems the lexer should pickup it's set of EOL Strings from the
format.
I recall reading worries of performance issues changing this but either we
support all of the EOL strings including some of the odd ball ones like
Unicode, or we do not. Perhaps we can have an alternate Lexer that takes a
set of EOL strings if performance is really that much worse.
Sounds reasonable, but seems to be a lot of work. Maybe we can just
document that 1.0 can only handle CR LF and add the ability for more
exotic record separators in 1.1. I'm hoping for higher adoption and more
patches once we have a release on maven central.
Benedikt
Gary
On Mon, Jul 7, 2014 at 1:47 PM, Benedikt Ritter brit...@apache.org
wrote:
Any thoughts about this fix? Could be a solution to push out 1.0. If we
come up with a more generic solution afterwards, we can still deprecate
escapeCRLFOnce.
Benedikt
-- Forwarded message --
From: Tillmann Gaida (JIRA) j...@apache.org
Date: 2014-06-30 10:36 GMT+02:00
Subject: [jira] [Comment Edited] (CSV-35) Escaped line separators are not
supported
To: brit...@apache.org
[
https://issues.apache.org/jira/browse/CSV-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14047460#comment-14047460
]
Tillmann Gaida edited comment on CSV-35 at 6/30/14 8:34 AM:
I added a patch commons-csv CSV-35 escapeCRLFOnce[ test].patch, which
introduces a CSVFormat setting escapeCRLFOnce, which enables the
desired
behaviour in Lexer. It is false by default and I did not change
CSVFormat.MYSQL, which might be approprate. I am not exactly happy with
the
naming of the setting. Consider renaming it if you happen to build upon
the
patch.
EDIT: clarity
EDIT: This is a very specific setting. A cleaner solution would probably
be
to allow escaping of record separators by a single escape char. However
it
appears that the MYSQL format uses LF as a record separator, so we would
need to have multiple record separators, which in this case would not be
actual record separators.
I'd argue that CRLF is special enough to have an individual setting, but
I
would also agree with having a cleaner CSVFormat. The only real
alternative
would be having a way to individually specify character sequences and a
replacement if they are preceded by the escape char.
was (Author: tillmann gaida):
I added a patch commons-csv CSV-35 escapeCRLFOnce[ test].patch, which
introduces a CSVFormat setting escapeCRLFOnce, which enables the
desired
behaviour in Lexer. It is false by default and I did not change
CSVFormat.MYSQL, which might be approprate. I am not exactly happy with
the
naming of the setting. Consider renaming it if you happen to build upon
the
patch.
EDIT: clarity
Escaped line separators are not supported
-
Key: CSV-35
URL: https://issues.apache.org/jira/browse/CSV-35
Project: Commons CSV
Issue Type: Bug
Reporter: Emmanuel Bourg
Fix For: 1.0
Attachments: CSV-35.patch, commons-csv CSV-35 escapeCRLFOnce
test.patch, commons-csv CSV-35 escapeCRLFOnce.patch,
mysql-export-line-terminated-by-crlf.csv,
mysql-export-line-terminated-by-lf.csv
Commons CSV doesn't handle escaped line separators, for example:
{code}
value1;value2;value3a\
value3b
{code}
In this case the expected result is:
{code}[value1, value2, value3a\nvalue3b]{code}
This kind of escaping is produced by MySQL, whether the field enclosing
is enabled or not. It's possible to see enclosing quotes and escaped line
separators like this:
{code}
value1;value2;value3a\
value3b
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
--
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
Re: svn commit: r1578191 - /commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVParser.java
Design philosophies like this should be documented in the project - that way there is no need to hash out the correct approach for every line of code. Everyone has different design philosophies, and in some cases there is no right or wrong philosophy. [In this thread, two fail-slow designs that provide default values, and one fail-fast design that throws an exception.] So, it helps if a project can state clearly its fundamental design philosophy. Some users might disagree with it, but at least it makes code maintenance and new development easier. Adrian Crum Sandglass Software www.sandglass-software.com On 3/17/2014 11:42 AM, Gary Gregory wrote: I re-implemented the simplest behavior (back to what we had before): null - IAE. Gary On Mon, Mar 17, 2014 at 2:31 PM, Emmanuel Bourg ebo...@apache.org wrote: Le 17/03/2014 19:21, Gary Gregory a écrit : OK, then we are back to null - exception. Check? I'd say default to the system encoding, like most methods of this kind. 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: [beanutils2] Assertions class vs. lang Validate
The Assertions class works fine and it serves its purpose. There is no need to make the library dependent on another library. Going that route, as a developer/user of the library, I would be forced to download and install two libraries instead of one. So it is more complication and work for me. Adrian Crum Sandglass Software www.sandglass-software.com On 3/3/2014 12:07 AM, Benedikt Ritter wrote: Hi Adrian 2014-03-02 8:03 GMT+01:00 Adrian Crum adrian.c...@sandglass-software.com: On 3/1/2014 9:33 AM, Benedikt Ritter wrote: I don't like the idea of creating some kind of component hierarchy, where components higher up may depend on lower levels libs. This should be decided for every individual case. I agree. If I just want some basic low-level library, I don't want it to have a multitude of silly dependencies. One of the main problems with this community is the top-down-one-size-fits-all mentality. It just makes things a lot harder than they should be from a user's/developer's perspective. I don't understand what you mean with this. Can you explain some more? Adrian Crum Sandglass Software www.sandglass-software.com - 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: [beanutils2] Assertions class vs. lang Validate
On 3/1/2014 9:33 AM, Benedikt Ritter wrote: I don't like the idea of creating some kind of component hierarchy, where components higher up may depend on lower levels libs. This should be decided for every individual case. I agree. If I just want some basic low-level library, I don't want it to have a multitude of silly dependencies. One of the main problems with this community is the top-down-one-size-fits-all mentality. It just makes things a lot harder than they should be from a user's/developer's perspective. Adrian Crum Sandglass Software www.sandglass-software.com - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SITE] New design is finally online
The site looks great! Thanks Benedikt! Adrian Crum Sandglass Software www.sandglass-software.com On 2/18/2014 9:51 AM, Benedikt Ritter wrote: Hi all, I've just published our website. The new skin is now online. [1] Since site publication takes a long time with my internet connection, I'll only publish a few components every day. Help is welcome here :-) Benedikt [1] http://commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Annotations
On 2/11/2014 4:53 PM, sebb wrote: On 11 February 2014 22:40, Thomas Neidhart thomas.neidh...@gmail.com wrote: On 02/10/2014 10:16 AM, Thomas Neidhart wrote: Hi, this is an issue I was thinking about for some time now, and it is quite some recurrent theme that we face in Commons. Considering our release practice, it is actually quite hard to come up with new features as the API is more or less fixed once it has been included. Ideally, this could or should be handled with alpha/beta releases were we gather feedback on a new API, but due to limited resources this does not seem feasible. From experience in Math we also see that when we want to extend an existing API for further uses, it is sometimes impossible to be backwards compatible simply because the original API did not foresee such things, which is quite normal I guess. Thus, I would like to discuss another approach. Add certain annotations to the code that clearly mark the mark the current state of a class/type and which allows us to break compatibility for such classes even in minor releases. As a first step I would foresee the following annotations: * Internal: Only for internal use, no guarantee about BC or may even be removed without warning * Beta: New API, may be changed in minor releases after gathering feedback from the community Additionally, I would like to introduce also the annotations from the jcip (jcip.net http://jcip.net). I do not know if we can add them as dependency, but we could also add them ourselves. IMO this would be of great benefit to our users if it is clear if a certain class is Immutable, ThreadSafe or Not and one does not have to analyze the source code to assert him/herself. I created a ticket for this, and started with two annotations so far: https://issues.apache.org/jira/browse/MATH-1098 So what do you think about that? It looks like I am pretty much the only one that sees a value in this stuff, so I guess it is better to not change anything. I am keen that code should be documented to say whether a class is supposed to be thread-safe / immutable / not thread-safe etc. Also to document how mutable variables are protected (@GuardedBy). I think this is important both for the user of the code, and particularly for the maintainer. There's no point struggling to ensure thread-safety for a class that is not intended to be shared across threads, equally if a class is supposed to be shareable it is vital to ensure updates don't break it. I think the best way of doing this is via annotations (plus inline comment if really needed). As an example of why I think annotations are better, compare: @GuardedBy(this) private int index; with /* * thread-safety of the index is guaranteed by synchronising on the class instance */ private int index; I use a similar approach in Apache OFBiz. The @ThreadSafe and @GuardedBy annotations really make it easier for me to understand how a block of code works - especially when I haven't touched the code in a while and I've forgotten those details. (Btw, I would recommend adding @ClassInvariant to the list.) If the annotation interfaces include the @Documented annotation, then the annotation is included in JavaDocs - so they aren't much different than JavaDoc comments. If a developer needs any more detail, they can go to the interface's JavaDocs. The annotations being proposed here are pretty basic and intuitive, so I don't see them as being some kind of hurdle a developer needs to overcome. Adrian Crum Sandglass Software www.sandglass-software.com - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: commons-lang pull request: add isNull and isNotNull methods
Personally, I view this as an anti-pattern. You have a null reference in your hand, and instead of checking the reference that is in your hand, you give it to an unrelated class and have that class check to see if it is a null reference. That just doesn't make any sense to me. Adrian Crum Sandglass Software www.sandglass-software.com On 2/4/2014 12:02 PM, otaviojava wrote: GitHub user otaviojava opened a pull request: https://github.com/apache/commons-lang/pull/16 add isNull and isNotNull methods Sugestion to add two simple and useful methods, with tests, on ObjectsUtil to get the code cleaner. isnull and isNotNull. So you can use if (ObjectUtil.isNull(value)) instead of if (value == null) the goal is the code more understandable. You can merge this pull request into a Git repository by running: $ git pull https://github.com/otaviojava/commons-lang trunk Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/16.patch commit 4f4d5b8eecdc61f22363d9d9883626549c12564a Author: otaviojava otavioj...@java.net Date: 2014-02-04T19:58:43Z add two simple and useful methods, with tests, on ObjectsUtil to get the code cleaner. isnull and isNotNull. - 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] CSVRecord and MapString, String
I agree with Emmanuel. We don't want CSVRecord to devolve into a god class that tries to be everything to everybody. Do only one thing, and do it really well is the design pattern I prefer. I created a patch for the design I proposed a few days ago. Please consider using it. https://issues.apache.org/jira/browse/CSV-104 Adrian Crum Sandglass Software www.sandglass-software.com On 1/22/2014 8:01 AM, Emmanuel Bourg wrote: Le 21/01/2014 15:08, Gary Gregory a écrit : This kind of complication is unnecessary IMO, why not just have the record implement Map? Because a record is neither a List nor a Map. A map decorator isn't that complicated, and the work has already been done in [configuration]. It would be trivial to adapt the code to [csv]. 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] CSVRecord and MapString, String
CORRECTION: The patch in the Jira issue is a simplified version of Gary's implementation. I started with the design I proposed - an inner class Map implementation backed by CSVRecord, but then implementing entrySet() and such became complicated. So I changed it to the inner class being backed by a HashMap, then reduced that to a simplified version of Gray's implementation. I apologize for the confusion. -Adrian Quoting Adrian Crum adrian.c...@sandglass-software.com: I agree with Emmanuel. We don't want CSVRecord to devolve into a god class that tries to be everything to everybody. Do only one thing, and do it really well is the design pattern I prefer. I created a patch for the design I proposed a few days ago. Please consider using it. https://issues.apache.org/jira/browse/CSV-104 Adrian Crum Sandglass Software www.sandglass-software.com On 1/22/2014 8:01 AM, Emmanuel Bourg wrote: Le 21/01/2014 15:08, Gary Gregory a écrit : This kind of complication is unnecessary IMO, why not just have the record implement Map? Because a record is neither a List nor a Map. A map decorator isn't that complicated, and the work has already been done in [configuration]. It would be trivial to adapt the code to [csv]. 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [csv] CSVRecord and MapString, String
I disagree. If the CSV record is read-only, then the List and Map representations of the CSV record should be read-only too. Making those representations writable is confusing - it gives the impression you are modifying the CSV record when in fact you are not. I don't see how it restricts their usability. -Adrian Quoting Gary Gregory garydgreg...@gmail.com: On Wed, Jan 22, 2014 at 9:40 AM, adrian.c...@sandglass-software.com wrote: CORRECTION: The patch in the Jira issue is a simplified version of Gary's implementation. I started with the design I proposed - an inner class Map implementation backed by CSVRecord, but then implementing entrySet() and such became complicated. So I changed it to the inner class being backed by a HashMap, then reduced that to a simplified version of Gray's implementation. I apologize for the confusion. I do not see the point of making the new objects (list, map) read-only. Since the objects are not connected to the record, there should be no expectancy of synchronizing the map with the record. There are to methods after all. This just restricts the usability of the objects. Gary -Adrian Quoting Adrian Crum adrian.c...@sandglass-software.com: I agree with Emmanuel. We don't want CSVRecord to devolve into a god class that tries to be everything to everybody. Do only one thing, and do it really well is the design pattern I prefer. I created a patch for the design I proposed a few days ago. Please consider using it. https://issues.apache.org/jira/browse/CSV-104 Adrian Crum Sandglass Software www.sandglass-software.com On 1/22/2014 8:01 AM, Emmanuel Bourg wrote: Le 21/01/2014 15:08, Gary Gregory a écrit : This kind of complication is unnecessary IMO, why not just have the record implement Map? Because a record is neither a List nor a Map. A map decorator isn't that complicated, and the work has already been done in [configuration]. It would be trivial to adapt the code to [csv]. 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 - 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [csv] CSVRecord and MapString, String
There is no question your use case is convenient, but it violates the
contract that a CSV record is read-only. Calling put() on a CSV record
is a mutating operation.
So, is a CSV record read-only or not?
-Adrian
Quoting Gary Gregory garydgreg...@gmail.com:
On Wed, Jan 22, 2014 at 10:04 AM, adrian.c...@sandglass-software.comwrote:
I disagree. If the CSV record is read-only, then the List and Map
representations of the CSV record should be read-only too. Making those
representations writable is confusing - it gives the impression you are
modifying the CSV record when in fact you are not.
I don't see how it restricts their usability.
I guess I should have started with another use-case: take a CSV, remove a
column, and compute a new column.
Right now I can do (to try, add this to CSVRecordTest):
@Test
public void testRemoveAndAddColumns() throws IOException {
// do:
final CSVPrinter printer = new CSVPrinter(new StringBuilder(),
CSVFormat.DEFAULT);
final MapString, String map = recordWithHeader.toMap();
map.remove(OldColumn);
map.put(NewColumn, NewValue);
// check:
final ArrayListString list = new ArrayListString(map.values());
Collections.sort(list);
printer.printRecord(list);
Assert.assertEquals(A,B,C,NewValue +
CSVFormat.DEFAULT.getRecordSeparator(), printer.getOut().toString());
}
I would have to create a wasteful temp Map if the Map I get from the record
is read-only. This code is bad enough.
If the record is a Map, there is no song and dance at all:
// do:
final CSVPrinter printer = new CSVPrinter(new StringBuilder(),
CSVFormat.DEFAULT);
recordWithHeader.remove(OldColumn);
recordWithHeader.put(NewColumn, NewValue);
// check:
printer.printRecord(recordWithHeader);
Assert.assertEquals(A,B,C,NewValue +
CSVFormat.DEFAULT.getRecordSeparator(), printer.getOut().toString());
If you want a special kind of Map (a blinking read-only map ;), you can
call putIn(Map).
Gary
-Adrian
Quoting Gary Gregory garydgreg...@gmail.com:
On Wed, Jan 22, 2014 at 9:40 AM, adrian.c...@sandglass-software.com
wrote:
CORRECTION: The patch in the Jira issue is a simplified version of Gary's
implementation.
I started with the design I proposed - an inner class Map implementation
backed by CSVRecord, but then implementing entrySet() and such became
complicated. So I changed it to the inner class being backed by a
HashMap,
then reduced that to a simplified version of Gray's implementation.
I apologize for the confusion.
I do not see the point of making the new objects (list, map) read-only.
Since the objects are not connected to the record, there should be no
expectancy of synchronizing the map with the record. There are to
methods
after all. This just restricts the usability of the objects.
Gary
-Adrian
Quoting Adrian Crum adrian.c...@sandglass-software.com:
I agree with Emmanuel. We don't want CSVRecord to devolve into a god
class that tries to be everything to everybody. Do only one thing, and
do
it really well is the design pattern I prefer.
I created a patch for the design I proposed a few days ago. Please
consider using it.
https://issues.apache.org/jira/browse/CSV-104
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/22/2014 8:01 AM, Emmanuel Bourg wrote:
Le 21/01/2014 15:08, Gary Gregory a écrit :
This kind of complication is unnecessary IMO, why not just have the
record
implement Map?
Because a record is neither a List nor a Map.
A map decorator isn't that complicated, and the work has already been
done in [configuration]. It would be trivial to adapt the code to
[csv].
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
-
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
-
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
Re: [csv] CSVRecord and MapString, String
Personally, I would like to see CSV record made mutable. You could get
one from the parser, make a few changes to it, then pass it to the
printer.
-Adrian
Quoting Gary Gregory garydgreg...@gmail.com:
On Wed, Jan 22, 2014 at 11:03 AM, adrian.c...@sandglass-software.comwrote:
There is no question your use case is convenient, but it violates the
contract that a CSV record is read-only. Calling put() on a CSV record is a
mutating operation.
So, is a CSV record read-only or not?
That the heart of the matter indeed.
For the sake of getting 1.0 out the door, we can leave it read-only.
If we want to make it read-write, we can do that later, in 1.1 or 2.0.
Whether or not this is done while preserving BC will be a different matter.
Gary
-Adrian
Quoting Gary Gregory garydgreg...@gmail.com:
On Wed, Jan 22, 2014 at 10:04 AM, adrian.c...@sandglass-software.com
wrote:
I disagree. If the CSV record is read-only, then the List and Map
representations of the CSV record should be read-only too. Making those
representations writable is confusing - it gives the impression you are
modifying the CSV record when in fact you are not.
I don't see how it restricts their usability.
I guess I should have started with another use-case: take a CSV, remove a
column, and compute a new column.
Right now I can do (to try, add this to CSVRecordTest):
@Test
public void testRemoveAndAddColumns() throws IOException {
// do:
final CSVPrinter printer = new CSVPrinter(new StringBuilder(),
CSVFormat.DEFAULT);
final MapString, String map = recordWithHeader.toMap();
map.remove(OldColumn);
map.put(NewColumn, NewValue);
// check:
final ArrayListString list = new ArrayListString(map.values()
);
Collections.sort(list);
printer.printRecord(list);
Assert.assertEquals(A,B,C,NewValue +
CSVFormat.DEFAULT.getRecordSeparator(), printer.getOut().toString());
}
I would have to create a wasteful temp Map if the Map I get from the
record
is read-only. This code is bad enough.
If the record is a Map, there is no song and dance at all:
// do:
final CSVPrinter printer = new CSVPrinter(new StringBuilder(),
CSVFormat.DEFAULT);
recordWithHeader.remove(OldColumn);
recordWithHeader.put(NewColumn, NewValue);
// check:
printer.printRecord(recordWithHeader);
Assert.assertEquals(A,B,C,NewValue +
CSVFormat.DEFAULT.getRecordSeparator(), printer.getOut().toString());
If you want a special kind of Map (a blinking read-only map ;), you can
call putIn(Map).
Gary
-Adrian
Quoting Gary Gregory garydgreg...@gmail.com:
On Wed, Jan 22, 2014 at 9:40 AM, adrian.c...@sandglass-software.com
wrote:
CORRECTION: The patch in the Jira issue is a simplified version of
Gary's
implementation.
I started with the design I proposed - an inner class Map
implementation
backed by CSVRecord, but then implementing entrySet() and such became
complicated. So I changed it to the inner class being backed by a
HashMap,
then reduced that to a simplified version of Gray's implementation.
I apologize for the confusion.
I do not see the point of making the new objects (list, map)
read-only.
Since the objects are not connected to the record, there should be no
expectancy of synchronizing the map with the record. There are to
methods
after all. This just restricts the usability of the objects.
Gary
-Adrian
Quoting Adrian Crum adrian.c...@sandglass-software.com:
I agree with Emmanuel. We don't want CSVRecord to devolve into a god
class that tries to be everything to everybody. Do only one thing,
and
do
it really well is the design pattern I prefer.
I created a patch for the design I proposed a few days ago. Please
consider using it.
https://issues.apache.org/jira/browse/CSV-104
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/22/2014 8:01 AM, Emmanuel Bourg wrote:
Le 21/01/2014 15:08, Gary Gregory a écrit :
This kind of complication is unnecessary IMO, why not just have the
record
implement Map?
Because a record is neither a List nor a Map.
A map decorator isn't that complicated, and the work has already been
done in [configuration]. It would be trivial to adapt the code to
[csv].
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
-
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
Re: svn commit: r1559905 - in /commons/proper/csv/trunk/src: main/java/org/apache/commons/csv/CSVRecord.java test/java/org/apache/commons/csv/CSVRecordTest.java
This looks really ugly. How do I update the CSVRecord using Map.put()?
Is there a reason you didn't use the design I proposed?
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/20/2014 9:12 PM, ggreg...@apache.org wrote:
Author: ggregory
Date: Tue Jan 21 02:12:02 2014
New Revision: 1559905
URL: http://svn.apache.org/r1559905
Log:
[CSV-105] Add Map conversion API to CSVRecord.
Modified:
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVRecord.java
commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVRecordTest.java
Modified:
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVRecord.java
URL:
http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVRecord.java?rev=1559905r1=1559904r2=1559905view=diff
==
---
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVRecord.java
(original)
+++
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVRecord.java
Tue Jan 21 02:12:02 2014
@@ -19,8 +19,10 @@ package org.apache.commons.csv;
import java.io.Serializable;
import java.util.Arrays;
+import java.util.HashMap;
import java.util.Iterator;
import java.util.Map;
+import java.util.Map.Entry;
/**
* A CSV record parsed from a CSV file.
@@ -168,6 +170,19 @@ public final class CSVRecord implements
}
/**
+ * Puts all values of this record into the given Map.
+ *
+ * @param map The Map to populate.
+ * @return the given map.
+ */
+public MapString, String putIn(MapString, String map) {
+for (EntryString, Integer entry : mapping.entrySet()) {
+map.put(entry.getKey(), values[entry.getValue().intValue()]);
+}
+return map;
+}
+
+/**
* Returns the number of values in this record.
*
* @return the number of values.
@@ -176,6 +191,15 @@ public final class CSVRecord implements
return values.length;
}
+/**
+ * Converts this record into a Map.
+ *
+ * @return A new Map. The map is empty if the record has no headers.
+ */
+public MapString, String toMap() {
+return putIn(new HashMapString, String(values.length));
+}
+
@Override
public String toString() {
return Arrays.toString(values);
Modified:
commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVRecordTest.java
URL:
http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVRecordTest.java?rev=1559905r1=1559904r2=1559905view=diff
==
---
commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVRecordTest.java
(original)
+++
commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVRecordTest.java
Tue Jan 21 02:12:02 2014
@@ -23,6 +23,7 @@ import static org.junit.Assert.assertTru
import java.util.HashMap;
import java.util.Map;
+import java.util.concurrent.ConcurrentHashMap;
import org.junit.Before;
import org.junit.Test;
@@ -37,7 +38,7 @@ public class CSVRecordTest {
@Before
public void setUp() throws Exception {
-values = new String[] { first, second, third };
+values = new String[] { A, B, C };
record = new CSVRecord(values, null, null, 0);
header = new HashMapString, Integer();
header.put(first, Integer.valueOf(0));
@@ -123,4 +124,31 @@ public class CSVRecordTest {
}
}
+@Test
+public void testPutInMap() {
+MapString, String map = new ConcurrentHashMapString, String();
+this.recordWithHeader.putIn(map);
+this.validateMap(map, false);
+}
+
+@Test
+public void testToMap() {
+MapString, String map = this.recordWithHeader.toMap();
+this.validateMap(map, true);
+}
+
+private void validateMap(MapString, String map, boolean allowsNulls) {
+assertTrue(map.containsKey(first));
+assertTrue(map.containsKey(second));
+assertTrue(map.containsKey(third));
+assertFalse(map.containsKey(fourth));
+if (allowsNulls) {
+assertFalse(map.containsKey(null));
+}
+assertEquals(A, map.get(first));
+assertEquals(B, map.get(second));
+assertEquals(C, map.get(third));
+assertEquals(null, map.get(fourth));
+}
+
}
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1559905 - in /commons/proper/csv/trunk/src: main/java/org/apache/commons/csv/CSVRecord.java test/java/org/apache/commons/csv/CSVRecordTest.java
I must be confused. If the goal was to give CSVRecord a Map interface, then that would include the interface's put method. If we don't support the Map interface, then what is the point of this change? Adrian Crum Sandglass Software www.sandglass-software.com On 1/21/2014 6:36 AM, Emmanuel Bourg wrote: Le 21/01/2014 12:20, Adrian Crum a écrit : This looks really ugly. How do I update the CSVRecord using Map.put()? Shouldn't the record be read only? As the result of a parsing it's not intended to be modified. 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: svn commit: r1559905 - in /commons/proper/csv/trunk/src: main/java/org/apache/commons/csv/CSVRecord.java test/java/org/apache/commons/csv/CSVRecordTest.java
Btw, line #179 - potential NPE. If CSVRecord is intended to be read-only, then the toMap() method should return an unmodifiable Map. Adrian Crum Sandglass Software www.sandglass-software.com On 1/21/2014 6:44 AM, Adrian Crum wrote: I must be confused. If the goal was to give CSVRecord a Map interface, then that would include the interface's put method. If we don't support the Map interface, then what is the point of this change? Adrian Crum Sandglass Software www.sandglass-software.com On 1/21/2014 6:36 AM, Emmanuel Bourg wrote: Le 21/01/2014 12:20, Adrian Crum a écrit : This looks really ugly. How do I update the CSVRecord using Map.put()? Shouldn't the record be read only? As the result of a parsing it's not intended to be modified. 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1559905 - in /commons/proper/csv/trunk/src: main/java/org/apache/commons/csv/CSVRecord.java test/java/org/apache/commons/csv/CSVRecordTest.java
http://mail-archives.apache.org/mod_mbox/commons-dev/201401.mbox/%3C52D5C3A7.4060004%40sandglass-software.com%3E
http://mail-archives.apache.org/mod_mbox/commons-dev/201401.mbox/%3C52D7C612.8040601%40sandglass-software.com%3E
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/21/2014 7:58 AM, Gary Gregory wrote:
On Tue, Jan 21, 2014 at 6:20 AM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
This looks really ugly. How do I update the CSVRecord using Map.put()?
Is there a reason you didn't use the design I proposed?
What design is that? Obviously not in this thread but a reference would be
helpful.
Gary
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/20/2014 9:12 PM, ggreg...@apache.org wrote:
Author: ggregory
Date: Tue Jan 21 02:12:02 2014
New Revision: 1559905
URL: http://svn.apache.org/r1559905
Log:
[CSV-105] Add Map conversion API to CSVRecord.
Modified:
commons/proper/csv/trunk/src/main/java/org/apache/commons/
csv/CSVRecord.java
commons/proper/csv/trunk/src/test/java/org/apache/commons/
csv/CSVRecordTest.java
Modified: commons/proper/csv/trunk/src/main/java/org/apache/commons/
csv/CSVRecord.java
URL: http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/
main/java/org/apache/commons/csv/CSVRecord.java?rev=
1559905r1=1559904r2=1559905view=diff
==
--- commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVRecord.java
(original)
+++ commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVRecord.java
Tue Jan 21 02:12:02 2014
@@ -19,8 +19,10 @@ package org.apache.commons.csv;
import java.io.Serializable;
import java.util.Arrays;
+import java.util.HashMap;
import java.util.Iterator;
import java.util.Map;
+import java.util.Map.Entry;
/**
* A CSV record parsed from a CSV file.
@@ -168,6 +170,19 @@ public final class CSVRecord implements
}
/**
+ * Puts all values of this record into the given Map.
+ *
+ * @param map The Map to populate.
+ * @return the given map.
+ */
+public MapString, String putIn(MapString, String map) {
+for (EntryString, Integer entry : mapping.entrySet()) {
+map.put(entry.getKey(), values[entry.getValue().
intValue()]);
+}
+return map;
+}
+
+/**
* Returns the number of values in this record.
*
* @return the number of values.
@@ -176,6 +191,15 @@ public final class CSVRecord implements
return values.length;
}
+/**
+ * Converts this record into a Map.
+ *
+ * @return A new Map. The map is empty if the record has no headers.
+ */
+public MapString, String toMap() {
+return putIn(new HashMapString, String(values.length));
+}
+
@Override
public String toString() {
return Arrays.toString(values);
Modified: commons/proper/csv/trunk/src/test/java/org/apache/commons/
csv/CSVRecordTest.java
URL: http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/
test/java/org/apache/commons/csv/CSVRecordTest.java?rev=
1559905r1=1559904r2=1559905view=diff
==
---
commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVRecordTest.java
(original)
+++
commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVRecordTest.java
Tue Jan 21 02:12:02 2014
@@ -23,6 +23,7 @@ import static org.junit.Assert.assertTru
import java.util.HashMap;
import java.util.Map;
+import java.util.concurrent.ConcurrentHashMap;
import org.junit.Before;
import org.junit.Test;
@@ -37,7 +38,7 @@ public class CSVRecordTest {
@Before
public void setUp() throws Exception {
-values = new String[] { first, second, third };
+values = new String[] { A, B, C };
record = new CSVRecord(values, null, null, 0);
header = new HashMapString, Integer();
header.put(first, Integer.valueOf(0));
@@ -123,4 +124,31 @@ public class CSVRecordTest {
}
}
+@Test
+public void testPutInMap() {
+MapString, String map = new ConcurrentHashMapString,
String();
+this.recordWithHeader.putIn(map);
+this.validateMap(map, false);
+}
+
+@Test
+public void testToMap() {
+MapString, String map = this.recordWithHeader.toMap();
+this.validateMap(map, true);
+}
+
+private void validateMap(MapString, String map, boolean
allowsNulls) {
+assertTrue(map.containsKey(first));
+assertTrue(map.containsKey(second));
+assertTrue(map.containsKey(third));
+assertFalse(map.containsKey(fourth));
+if (allowsNulls) {
+assertFalse(map.containsKey(null));
+}
+assertEquals(A, map.get(first));
+assertEquals(B, map.get(second));
+assertEquals(C, map.get(third));
+assertEquals(null
Re: [csv] CSVRecord and MapString, String
It might help to step back from the story and look at it from the perspective of a Commons CSV user who is familiar with using Maps. How should a Map derived from a CSVRecord behave? What happens with the put() and putAll() methods? What happens when get() and put() are called with invalid keys? Is the CSVRecord-derived Map going to behave differently than any other Map in a significant way? If yes, do we really want to do that? Adrian Crum Sandglass Software www.sandglass-software.com On 1/21/2014 8:04 AM, Gary Gregory wrote: My story: There should be some kind of play between a CSVRecord and a MapString, String. My current app requires only reading, not writing. Solutions: - CSVRecord implements MapString, String - CSVRecord implements MapString, String but read-only - CSVRecord implements toMap() - MapString, String (a plain HashMap) - CSVRecord implements toMap() - MapString, String (a read-only HashMap) - Split CSVRecord into a CSVMappedRecord subclass which can implement one of the above. Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [csv] CSVRecord implements MapString, String
CSVRecordMap implements MapString, String {
CSVRecordMap(CSVRecord record) {
}
}
Use the Map implementation to access the record in a Map-like way, use
the CSVRecord instance to access the record in a List-like way.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/16/2014 1:04 AM, Gary Gregory wrote:
Maybe we _should_ revisit splitting the record class. Now, we have the
following slots:
CSVRecord:
comment : String
mapping : MapString, Integer
recordNumber : long
values : String[]
If we take out mapping and put in it a subclass, that reduces the size of
the plain record by 25%:
CSVRecord:
comment : String
recordNumber : long
values : String[]
CSVRecordMap extends CSVRecord
mapping : MapString, Integer
or:
CSVRecordMap extends CSVRecord implements MapString, String
mapping : MapString, Integer
Thoughts?
Gary
On Wed, Jan 15, 2014 at 11:22 AM, Emmanuel Bourg ebo...@apache.org wrote:
Le 15/01/2014 07:17, Benedikt Ritter a écrit :
A wrapper of some kind like Adrian suggested sounds like the way to go
here. Maybe we could have something like:
MapString, String map = CSVRecordUtils.toMap(record);
I had something like that in mind too, but I would rather use
record.toMap() and avoid exposing a new class.
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] CSVRecord implements MapString, String
That would only work if the CSV file had column names. Maybe make a class that implements Map and contains a CSVRecord - so it's optional. Adrian Crum Sandglass Software www.sandglass-software.com On 1/14/2014 5:27 PM, Gary Gregory wrote: Hi All: Any thoughts on making CSVRecord implement MapString, String ? It would certainly help remove duplicate code in a use case of mine. Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [help] restoring javadocs to site
I could never get that to work for Convert either. I just update the site manually by committing the local changes. Adrian Crum Sandglass Software www.sandglass-software.com On 12/30/2013 7:04 PM, Phil Steitz wrote: I ran with scissors and tried mvn site-deploy and it seems to have (sic) *deleted* the previous javadoc versions from the site svn. How can I get these back? How can I avoid this trauma each time I try to publish the site? I guess I can just cp the local mvn site gen to a direct checkout the svn pub-sub. Is that what others do? Sorry I probably missed good instructions on this somewhere. Phil - 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: [DRAFT][REPORT] Status report for the Apache Commons Project December 2013
Try this: http://commons.markmail.org/ Adrian Crum Sandglass Software www.sandglass-software.com On 12/9/2013 12:17 PM, Stefan Bodewig wrote: On 2013-12-09, Gary Gregory wrote: Thank you for the corrections. I do not see how to get mailing list stats out of ezmlm. http://pulse.apache.org/#commons.apache.org Report looked fine to me. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Removing websites of dormant components
You can remove the dormant convert. A new version is in the sandbox and I doubt anything will be done with the dormant version. Adrian Crum Sandglass Software www.sandglass-software.com On 11/29/2013 8:24 AM, Christian Grobmeier wrote: On 19.10. I wrote a mail in response to Henri Yandell. http://markmail.org/message/c63kqyipuy6islib I would like to follow up on the issues i mentioned there. Our dormant components are unmaintained and our dormant websites are broken. Therefore I would like to remove the websites. In example we are having this critical and wellknown security problem: http://www.kb.cert.org/vuls/id/225657 http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html At all these pages: http://commons.apache.org/dormant/cache/apidocs/index.html http://commons.apache.org/dormant/contract/apidocs/index.html http://commons.apache.org/dormant/convert/apidocs/index.html http://commons.apache.org/dormant/events/apidocs/index.html http://commons.apache.org/dormant/feedparser/apidocs/index.html http://commons.apache.org/dormant/jjar/apidocs/index.html http://commons.apache.org/dormant/latka/apidocs/index.html http://commons.apache.org/dormant/mapper/apidocs/index.html http://commons.apache.org/dormant/messenger/apidocs/index.html http://commons.apache.org/dormant/resources/apidocs/index.html http://commons.apache.org/dormant/scaffold/apidocs/index.html http://commons.apache.org/dormant/threadpool/apidocs/index.html http://commons.apache.org/dormant/workflow/apidocs/index.html http://commons.apache.org/dormant/xmlio/apidocs/index.html In addition none of the dormant components are respecting the trademark branding guidelines: http://www.apache.org/foundation/marks/pmcs.html If there is nobody who wants to fix these within a short timeframe I believe we should remove the websites from our server and forwarding it to maybe a wiki page which explains that docs of dormant components can only be retrieved by checking out the source code. Cheers, Christian --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - 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] Controlled and and assisted switch to Git
git stash is the same as svn create patch and revert. So, you're creating a local patch, reverting your local changes, updating your local copy from the repo (git pull), then git stash pop will restore your previous local changes - the same as svn apply patch. The only way that using git instead of svn will become easy is by doing it - like anything else. Adrian Crum Sandglass Software www.sandglass-software.com On 11/27/2013 7:47 AM, Gilles wrote: On Wed, 27 Nov 2013 12:44:27 +0100, Emmanuel Bourg wrote: Le 27/11/2013 12:13, Gilles a écrit : I'm only a bit worried about the timing, and whether knowledgeable people will be willing to detail the move and explain what to do to so that the total ignorant can indeed continue contributing à la svn[1] until he finds the time to study the more advanced features. If you don't apply a fancy branch model Git can be used just like Subversion Checkout: git clone url Commit all changes: git commit -a git push Update from the repository: git pull Quite clear up to here. The one thing Git doesn't do as well as Subversion is merging the local changes with the remote changes when updating the local copy. He will refuse to update the local copy if there are conflicting changes. In this case you either have to commit your local modifications, or stash them before updating. You can then resolve the conflicts as usual. git stash git pull git stash pop What is stash, what is stash pop? You see, from my zero knowledge, I infer from a previous post that some non-committer contributor can provide an outdated patch, and I, as a committer, should still be able to commit it (i.e. without asking him to update the patch with the newer trunk). How? On what condition is it possible, and when does that approach become impossible? So I could say that the limitations of the current system have the good consequence that contributors and committers are _obliged_ to work together. [E.g. the contributor of an old patch must stick around or, if he didn't, that could hint that it could be risky to commit a (non-trivial) code with nobody to maintain it.] Thus, IIUC, in the new system the committers will somehow be expected to do more work, since Git makes it possible to easily integrate/merge (?) individual repositories. This is enough to get started. You can then learn gradually how to play with branches, tags, remotes. Gradually? That's my fear (and problem). I should be able to prepare a release by simply following the (updated) recipe in doc/release/release.howto.txt, i.e. without any assumption which a seasoned Git-user would consider trivial. Thanks, Gilles [1] Describing one and only one fail-safe way. http://git-scm.com/book - 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: [validator] EmailValidator, DomainValidator questions
We really need to remove the TLD check from domain validation. noplace.somedog is a valid domain in the sense that it is properly formatted, but it is not a valid domain in the sense that the TLD does not exist. That distinction is missing in the domain Validator. It would be best to have two methods: one that checks the domain format, and another that checks if the domain exists. Adrian Crum Sandglass Software www.sandglass-software.com On 11/22/2013 8:07 AM, Jaun Oliver wrote: Hi I have got some questions regarding the EmailValidator. The documentation states: This implementation is not guaranteed to catch all possible errors in an email address. For example, an address like nobody@noplace.somedog will pass validator, even though there is no TLD somedog. This is not true. When I try to validate the mentioned address nobody@noplace.somedog the validator returns false. The Validator does actually check the top-level domain. A look at the code reveals that this is done using the DomainValidator. And here is the second finding: The domain list is not up-to-date. I understand that the recently released top-level domains like .kitchen, .tattoo and .bike are not supported yet (see http://newgtlds.icann.org//en/program-status/delegated-strings). But top level domains like XN--3E0B707E, XN--45BRJ9C and XN--80AO21A exist much longer (the first one since 2011). The Author of the DomainValidator class also mentions the Authoritative and comprehensive list at http://data.iana.org/TLD/tlds-alpha-by-domain.txt; which does include these domains. Are there any plans to update this list? Regards Oliver In der elektronischen Korrespondenz kann die im Schriftverkehr übliche Vertraulichkeit nicht gewährleistet werden. Bitte überprüfen Sie daher sorgfältig, welche Mitteilungen und Beilagen Sie per E-Mail senden und erhalten möchten. Falls Sie dieses E-Mail irrtümlicherweise erhalten haben, bitten wir Sie, die absendende Person zu kontaktieren und dieses E-Mail mit allen Anhängen von Ihrem System zu löschen. Avec la communication par courrier électronique, la confidentialité des informations n'est pas garantie comme elle l'est usuellement dans la correspondance écrite. Veuillez donc être vigilant lorsque vous envoyez ou recevez des communications et pièces jointes par courriel. Si vous avez reçu ce courriel par erreur, nous vous prions de contacter l'expéditeur/trice et de l'effacer avec toutes les pièces jointes de votre système. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Welcome to the new Apache Commons PMC chair: Gary Gregory
Congrats Gary! Adrian Crum Sandglass Software www.sandglass-software.com On 11/22/2013 9:19 AM, Luc Maisonobe wrote: Hi all, The Apache board meeting was held on wednesday. The resolution we proposed to change Apache Commons VP has been adopted, and its result can be seen here: http://www.apache.org/foundation/. I would like to thank Gary for accepting the position and to all of you for your help during my term. best regards, Luc - 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] commit screw-up
With Tortoise SVN it's easy. Right-click on your local copy, select Tortoise SVN - Show Log. Right-click on your commit, select Revert changes from this revision. Commit. Adrian Crum Sandglass Software www.sandglass-software.com On 10/19/2013 11:22 PM, Phil Steitz wrote: I inadvertently committed some WIP on Kolmogorov-Smirnov test implementation (MATH-437) in r1533853, in which I meant only to fix some javadoc in BinomialConfidenceInterval. The commit copies the existing implementation from the distribution package and makes some mods to it. I did it this way to preserve history of the code that is being kept. The code is not finished, has some checkstyle issues, but it should build OK. I am not sure exactly how to undo this in svn so I can redo it later and I would prefer to just edit the commit log and finish the code that I was planning to commit later in subsequent commits. Are people OK with this, or should I try to back out the copy / add? Maybe I need some of that git change-stashing capability ;) On the other hand, I am sure I will manage to screw up git commits in myriad other ways... Phil - 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: New committers: Ate Douma and Woonsan Ko
Congratulations to Ate Douma and Woonsan Ko! Adrian Crum Sandglass Software www.sandglass-software.com On 10/14/2013 10:51 AM, Luc Maisonobe wrote: Hi all, Please welcome Ate Douma and Woonsan Ko as a new committers of the Apache Commons project. The Commons PMC has voted to grant committership to them and they accepted. Both accounts have already been set up and they can begin working on the Commons components. Ate and Woonsan, welcome to the team ! Luc Maisonobe, on behalf of Apache Commons PMC - 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: [CHALLENGE] Move All of Commons to the Dormant
I am willing to help out with CSV. ID = adrianc. Adrian Crum Sandglass Software www.sandglass-software.com On 10/14/2013 9:14 PM, Phil Steitz wrote: On 10/14/13 8:55 PM, Henri Yandell wrote: I contend that all of the Commons components are inactive and should move to the Attic/Dormant. In line with Phil's recent suggestion that anyone can present a dormancy challenge at any time, I'm challenging all of Commons Proper. I've made a file in SVN: https://svn.apache.org/repos/asf/commons/trunks-proper/CHALLENGE.txt If committers could put their ids next to components they actively monitor the commits, JIRA, mailing list for, then we can determine, by elimination, the components that should be considered for dormancy. Thanks, Hen! Lets see who has a pulse ;) Lets also let non-committers chime in, though. I will volunteer to be commit monkey on this file for anyone not a commons committer who really wants to work on something. Phil I propose we review the state of the file at the start of November :) Hen - 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: [CHALLENGE] Move All of Commons to the Dormant
Thanks! I'm a committer in the sandbox, but I haven't ventured into proper yet. I was hoping to get Commons Convert promoted to proper someday. In the meantime I would be happy to work on CSV. Adrian Crum Sandglass Software www.sandglass-software.com On 10/14/2013 9:32 PM, Phil Steitz wrote: On 10/14/13 9:26 PM, Adrian Crum wrote: I am willing to help out with CSV. ID = adrianc. Done :) Phil Adrian Crum Sandglass Software www.sandglass-software.com On 10/14/2013 9:14 PM, Phil Steitz wrote: On 10/14/13 8:55 PM, Henri Yandell wrote: I contend that all of the Commons components are inactive and should move to the Attic/Dormant. In line with Phil's recent suggestion that anyone can present a dormancy challenge at any time, I'm challenging all of Commons Proper. I've made a file in SVN: https://svn.apache.org/repos/asf/commons/trunks-proper/CHALLENGE.txt If committers could put their ids next to components they actively monitor the commits, JIRA, mailing list for, then we can determine, by elimination, the components that should be considered for dormancy. Thanks, Hen! Lets see who has a pulse ;) Lets also let non-committers chime in, though. I will volunteer to be commit monkey on this file for anyone not a commons committer who really wants to work on something. Phil I propose we review the state of the file at the start of November :) Hen - 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] Putting several unmaintained components to dormant
What criteria are you using to come up with this list? Adrian Crum Sandglass Software www.sandglass-software.com On 10/9/2013 12:17 PM, Benedikt Ritter wrote: Hi, I think Phil came up with the idea to try to focus on the components that we are able to maintain and put all other stuff to dormant. Here is the list of components that I think really are proper: - CLI - Codec - Collections - Compress - Configuration - CSV - Daemon - DBCP (?) - Email - Functor - Imaging (?) - IO - JCI - Lang - Logging - Math - Net - Pool (?) - Proxy - SCXML (after recent interest) - VFS - Weaver All other stuff can go dormant because there is currently nobody who maintains it. Still a pretty long list. Thoughts? Anything missing? Benedikt - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] Putting several unmaintained components to dormant
Can we include commit activity and Jira activity in the analysis? Adrian Crum Sandglass Software www.sandglass-software.com On 10/9/2013 1:04 PM, Benedikt Ritter wrote: I've looked at all the proper components and listed all components where I've seen activity since I'm subscribed to the ML. 2013/10/9 Adrian Crum adrian.c...@sandglass-software.com What criteria are you using to come up with this list? Adrian Crum Sandglass Software www.sandglass-software.com On 10/9/2013 12:17 PM, Benedikt Ritter wrote: Hi, I think Phil came up with the idea to try to focus on the components that we are able to maintain and put all other stuff to dormant. Here is the list of components that I think really are proper: - CLI - Codec - Collections - Compress - Configuration - CSV - Daemon - DBCP (?) - Email - Functor - Imaging (?) - IO - JCI - Lang - Logging - Math - Net - Pool (?) - Proxy - SCXML (after recent interest) - VFS - Weaver All other stuff can go dormant because there is currently nobody who maintains it. Still a pretty long list. Thoughts? Anything missing? Benedikt --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-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: [DISCUSS] Putting several unmaintained components to dormant
That is a good point. Those Commons GPG commits are just Maven black box updates. Adrian Crum Sandglass Software www.sandglass-software.com On 10/9/2013 1:28 PM, Christian Grobmeier wrote: Here is some commit activity: http://svnsearch.org/svnsearch/repos/ASF/search?view=plotfrom=20130101to=20131009path=%2Fcommons%2Fproperplotsort=%24plotsort But we should to exclude typo fixes and such. For example: http://svnsearch.org/svnsearch/repos/ASF/search?view=resultlistfrom=20130101to=20131009path=%2Fcommons%2Fproper%2Fcommons-gpg-pluginplotsort=%24plotsort 22 changes on commons gpg, but not really meaningful changes. I would not consider Commons GPG as maintained. Jira doesn't mean much to me. Users can submit issues, but this doesn't mean a component is maintained. Even when 20 issues were submitted for GPG, it would not consider it maintained. On 9 Oct 2013, at 22:06, Adrian Crum wrote: Can we include commit activity and Jira activity in the analysis? Adrian Crum Sandglass Software www.sandglass-software.com On 10/9/2013 1:04 PM, Benedikt Ritter wrote: I've looked at all the proper components and listed all components where I've seen activity since I'm subscribed to the ML. 2013/10/9 Adrian Crum adrian.c...@sandglass-software.com What criteria are you using to come up with this list? Adrian Crum Sandglass Software www.sandglass-software.com On 10/9/2013 12:17 PM, Benedikt Ritter wrote: Hi, I think Phil came up with the idea to try to focus on the components that we are able to maintain and put all other stuff to dormant. Here is the list of components that I think really are proper: - CLI - Codec - Collections - Compress - Configuration - CSV - Daemon - DBCP (?) - Email - Functor - Imaging (?) - IO - JCI - Lang - Logging - Math - Net - Pool (?) - Proxy - SCXML (after recent interest) - VFS - Weaver All other stuff can go dormant because there is currently nobody who maintains it. Still a pretty long list. Thoughts? Anything missing? Benedikt --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-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://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - 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: [DISCUSS] Mission Statement for Commons...
I would like to know the metrics for that conclusion. I see plenty of discussions and commits, but I'm not seeing any languishing. Adrian Crum Sandglass Software www.sandglass-software.com On 10/6/2013 11:30 AM, James Carman wrote: All, The Apache Commons project seems to be languishing as of late and we need some rejuvenation. Perhaps we should try to define our mission as a project. What are our goals? What do we want to accomplish? Who are our users/customers? What non-functional qualities do we want our software to exhibit? How do we want to conduct ourselves? How often do we want to do releases? What else? Sincerely, James - 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] should CSVRecord's values() method be public?
I needed access to that method too, so I made that method public in my local copy. Adrian Crum Sandglass Software www.sandglass-software.com On 9/15/2013 12:05 PM, Michele Rossi wrote: hi, I am trying to use commons-csv for a simple CSV transformation tool and I have encountered a couple of issues that I would like to discuss. The CSVPrinter takes object arrays as input but the values method of CSVRecord is not public. In the code I am writing I check a condition to determine whether I should transform the CSVRecord or not. But the if that condition returns false I am forced to make an akward copy of the CSVRecord in an object array as - CSVRecord objects can not be fed to CSVPrinter - CSVRecord's values() method is not public If values() was public I could use the data read from one CSV to directly feed another CSV. Seems a reasonable use case. Also, shouldn't CSVRecord implement MapString, String ? The key could be the column header. It would make sense right? Or am I missing something? thanks, Michele - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[KARMA] Re: [jira] [Created] (SANDBOX-461) FloatToString
I need someone to grant me permission to manage Jira sandbox issues. My
Jira login ID is adri...@hlmksw.com
Thanks!
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 9/13/2013 3:48 PM, Brad Davis (JIRA) wrote:
Brad Davis created SANDBOX-461:
--
Summary: FloatToString
Key: SANDBOX-461
URL: https://issues.apache.org/jira/browse/SANDBOX-461
Project: Commons Sandbox
Issue Type: Bug
Components: Convert
Affects Versions: Nightly Builds
Reporter: Brad Davis
FloatToString seems to return unexpected results.
Test Case:
@Test
public void testFloatFormat() throws Exception {
Float testFloat = new Float(100.1878783420);
FloatToString fts = new FloatToString();
String format = ###.##;
String v1 = fts.convert(new Float(100.1878783420), Locale.US,
TimeZone.getDefault(), format);
NumberFormat nf = new DecimalFormat(###.##);
String v2 = nf.format(testFloat.floatValue());
Assert.assertEquals(100.19, v1);
Assert.assertEquals(100.19, v2);
}
This class may be the cause:
public static abstract class AbstractNumberConverterS, T extends
AbstractLocalizedConverterS, T {
It seems to drop the format string.
Also, the method:
protected String format(Float obj, NumberFormat nf) throws
ConversionException {
Should be made public to work around the issue if you want to , for
example, provide the DecimalFormat to the converter.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
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: [KARMA] Re: [jira] [Created] (SANDBOX-461) FloatToString
It works. Thanks!
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 9/14/2013 12:06 PM, Luc Maisonobe wrote:
Hi Adrian,
Le 14/09/2013 16:37, Adrian Crum a écrit :
I need someone to grant me permission to manage Jira sandbox issues. My
Jira login ID is adri...@hlmksw.com
Could you check if ti works now?
Luc
Thanks!
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 9/13/2013 3:48 PM, Brad Davis (JIRA) wrote:
Brad Davis created SANDBOX-461:
--
Summary: FloatToString
Key: SANDBOX-461
URL: https://issues.apache.org/jira/browse/SANDBOX-461
Project: Commons Sandbox
Issue Type: Bug
Components: Convert
Affects Versions: Nightly Builds
Reporter: Brad Davis
FloatToString seems to return unexpected results.
Test Case:
@Test
public void testFloatFormat() throws Exception {
Float testFloat = new Float(100.1878783420);
FloatToString fts = new FloatToString();
String format = ###.##;
String v1 = fts.convert(new Float(100.1878783420), Locale.US,
TimeZone.getDefault(), format);
NumberFormat nf = new DecimalFormat(###.##);
String v2 = nf.format(testFloat.floatValue());
Assert.assertEquals(100.19, v1);
Assert.assertEquals(100.19, v2);
}
This class may be the cause:
public static abstract class AbstractNumberConverterS, T extends
AbstractLocalizedConverterS, T {
It seems to drop the format string.
Also, the method:
protected String format(Float obj, NumberFormat nf) throws
ConversionException {
Should be made public to work around the issue if you want to , for
example, provide the DecimalFormat to the converter.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
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
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[ALL] Re: [jira] [Created] (SANDBOX-461) FloatToString
I need someone to grant me permission to manage Jira sandbox issues. My
Jira login ID is adri...@hlmksw.com
Thanks!
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 9/13/2013 3:48 PM, Brad Davis (JIRA) wrote:
Brad Davis created SANDBOX-461:
--
Summary: FloatToString
Key: SANDBOX-461
URL: https://issues.apache.org/jira/browse/SANDBOX-461
Project: Commons Sandbox
Issue Type: Bug
Components: Convert
Affects Versions: Nightly Builds
Reporter: Brad Davis
FloatToString seems to return unexpected results.
Test Case:
@Test
public void testFloatFormat() throws Exception {
Float testFloat = new Float(100.1878783420);
FloatToString fts = new FloatToString();
String format = ###.##;
String v1 = fts.convert(new Float(100.1878783420), Locale.US,
TimeZone.getDefault(), format);
NumberFormat nf = new DecimalFormat(###.##);
String v2 = nf.format(testFloat.floatValue());
Assert.assertEquals(100.19, v1);
Assert.assertEquals(100.19, v2);
}
This class may be the cause:
public static abstract class AbstractNumberConverterS, T extends
AbstractLocalizedConverterS, T {
It seems to drop the format string.
Also, the method:
protected String format(Float obj, NumberFormat nf) throws ConversionException {
Should be made public to work around the issue if you want to , for example,
provide the DecimalFormat to the converter.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [continuum] BUILD FAILURE: Apache Commons - Commons Configuration - Group (shared) Maven 3 Build Definition (Java 1.6)
In my experience, SVN update is unreliable for CI environments, so I always use a fresh checkout. Adrian Crum Sandglass Software www.sandglass-software.com On 9/11/2013 1:51 PM, sebb wrote: The group build definition is set to use SCM update rather than a clean checkout. However surely svn update should remove deleted files? Dunno what the bug is here. Changing to clean checkout for all Commons components seems unnecessary. But a temporary change + forced build + revert the change should fix it. I'll try that shortly. On 11 September 2013 21:26, Oliver Heger oliver.he...@oliver-heger.de wrote: Hm, seems that continuum operates on a dirty working copy. The class it reports a compilation error no longer exists in this package (it has been moved). Does anybody know how to fix this? [INFO] - [ERROR] COMPILATION ERROR : [INFO] - [ERROR] /home/continuum/continuum-base/data/working-directory/72/src/main/java/org/apache/commons/configuration/FileSystem.java:[114,29] cannot find symbol symbol : class DefaultFileSystem location: class org.apache.commons.configuration.FileSystem [ERROR] /home/continuum/continuum-base/data/working-directory/72/src/main/java/org/apache/commons/configuration/FileSystem.java:[137,25] cannot find symbol symbol : class DefaultFileSystem location: class org.apache.commons.configuration.FileSystem [INFO] 2 errors [INFO] - [INFO] [INFO] BUILD FAILURE Oliver Am 11.09.2013 22:20, schrieb Continuum@vmbuild: Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=27463projectId=72 Build statistics: State: Failed Previous State: Failed Started at: Wed 11 Sep 2013 20:20:07 + Finished at: Wed 11 Sep 2013 20:20:30 + Total time: 22s Build Trigger: Schedule Build Number: 299 Exit code: 1 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version 1.6.0_30 Java(TM) SE Runtime Environment (build 1.6.0_30-b12) Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode) Builder version : Apache Maven 3.0.2 (r1056850; 2011-01-09 00:58:10+) Java version: 1.6.0_30, vendor: Sun Microsystems Inc. Java home: /usr/lib/jvm/jdk1.6.0_30/jre Default locale: en_US, platform encoding: ANSI_X3.4-1968 OS name: linux, version: 2.6.32-41-server, arch: amd64, family: unix SCM Changes: Changed: oheger @ Wed 11 Sep 2013 19:37:10 + Comment: CatalogResolver no longer uses FileSystem.getInputStream(String, String). Instead, in a first step a URL is retrieved via FileLocatorUtils.locate(). Then from the URL an input stream is opened. After this change, FileSystem's getInputStream(String, String) method is no longer used. Files changed: /commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/resolver/CatalogResolver.java ( 1522004 ) Changed: oheger @ Wed 11 Sep 2013 19:37:53 + Comment: Removed getInputStream(String, String) method from FileSystem. This method is no longer called by any component. Files changed: /commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/io/DefaultFileSystem.java ( 1522005 ) /commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/io/FileSystem.java ( 1522005 ) /commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/io/VFSFileSystem.java ( 1522005 ) 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.2 Description: Group (shared) Maven 3 Build Definition (Java 1.6) Test Summary: Tests: 0 Failures: 0 Errors: 0 Total time: 0.0 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src: main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
I've seen a lot of discussions on NPE versus IAE, and in the end they
all condense down to what Matt stated here: Those who favor NPE cite the
JDK classes as a pattern to follow, and those who favor IAE say it is a
better description of the problem. From my perspective, both are valid
viewpoints, and a project simply needs to choose one. In the end, the
choice is neither right nor wrong - it is just a choice.
-Adrian
On 8/30/2013 8:07 AM, Matt Benson wrote:
Let me stir the pot:
At a fundamental level I agree that a required *argument* should throw an
IllegalArgumentException when null is supplied. However, ISTR the decision
to do otherwise in [lang] having been discussed on-list in the
not-so-distant past, and the result of that discussion being that NPE is
usually the result in the core JDK classes. So I wouldn't characterize the
situation as [lang] *just happens* to throw NPE. Now, [lang] is in a
slightly unique situation as its stated mission is to complement Java SE,
so it could be argued that [lang] is under greater pressure to conform for
that reason. But my personal preference, in light of the standing decision
with [lang], would be for consistency throughout Commons components
*despite* the fact that at a purely semantic level I agree with the
arguments in favor of IllegalArgumentException.
To summarize, +1 for NullPointerException from me.
Matt
On Fri, Aug 30, 2013 at 9:36 AM, Benedikt Ritter brit...@apache.org wrote:
2013/8/30 sebb seb...@gmail.com
On 30 August 2013 15:19, Benedikt Ritter brit...@apache.org wrote:
I've removed the generics in r1518974, thanks for spotting that sebb.
Regarding the exception to throw I'm indifferent. The important thing
is
to
fail early.
... and with a helpful message.
I personally thing that NPE should be reserved for signaling that some
code
tried to invoke a method on a null reference.
+1
In our case null is illegal because we know that some code later on
would
break if we accept a null reference. So IllegalStateException makes
sense.
s/IllegalStateException /IllegalArgumentException/
+1
Sorry, I meant IAE of corse.
Imaging having a method that accepts an int and only positive ints are
valid. You would throw an IllegalArgumentException if a negative int is
passed to that method and not a NegativeIntegerException (or what
ever).
But James has a point. If [LANG] uses NPE maybe we should stick to
this.
I don't think we have to do the same as LANG, so long as the Javadoc is
clear.
Feel free to change it. I'll leave it for now since there doesn't seem
to
be consensus?!
Unless there are other reasons than LANG happens to use NPE I think
we should stick with IAE, as it more clearly indicates the the problem
is not within the method throwing it.
The problem with using NPE to flag parameter errors is that it
confuses the user as to the likely cause.
Leave NPEs to the runtime system.
agreed.
Benedikt
2013/8/30 James Carman ja...@carmanconsulting.com
Well, the problem with using NPE is that we as Java developers have
learned through the years that NPE typically is an oh crap
situation, where something is terribly wrong (we hate seeing those).
Thus, our users may have knee-jerk reactions and not even know to
inspect the message for the real cause. IAE is less alarming, IMHO.
Just my $0.02, but we've been doing it that way for a long time in
[lang], so be it.
On Fri, Aug 30, 2013 at 9:01 AM, sebb seb...@gmail.com wrote:
AFAIK accidental NPEs don't have a message associated with them.
So provided that the assertion generates the NPE with a suitable
message (e.g.as currently done for the IAE) then it *should* be
possible for the end user to distinguish the two cases.
I am slightly in favour of retaining IAE as the cause is obvious
with
needing to look at the NPE message.
==
Horrible hack: - if you want to use NPE, you could wrap an IAE in
the
NPE:
npe = new NPE(msg);
npe.initCause(new IAE(msg));
throw npe;
Or vice-vera, of course!
Not sure that gains anything, but it does make the stack trace look
more impressive!
On 30 August 2013 13:42, James Carman ja...@carmanconsulting.com
wrote:
Commons Lang's Validate.notNull() throws NPEs. I don't know that
I've
necessarily agreed with that, but at some point a decision was made
that null constraint violations should throw NPEs. Food for
thought.
On Fri, Aug 30, 2013 at 8:32 AM, Gary Gregory
garydgreg...@gmail.com
wrote:
On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg
ebo...@apache.org
wrote:
+if (parameter == null) {
+throw new IllegalArgumentException(Parameter '
+
parameterName + ' must not be null!);
+}
+}
+}
Isn't a null value supposed to throw a NPE ?
Not always IMO. When I see an NPE I assume something is very wrong
and
that
it could be a bug in the impl OR a call site, somewhere on the
code
path.
With an IAE, I know for sure it's a problem in the call site
(which
could
be a bug of
Re: [ALL] Design question: static utility classes
+1 -Adrian On 8/25/2013 9:26 AM, James Carman wrote: AtomicReference? On Sunday, August 25, 2013, Phil Steitz wrote: On 8/24/13 11:33 AM, Oliver Heger wrote: Hi all, regarding a principle design question I would like to get your opinion: In [configuration] there are a few static utility classes. One of them is BeanHelper which supports the creation of beans from configuration data. The actual bean creation is done by a BeanFactory which can be configured using the static (currently unsynchronized) setDefaultBeanFactory() method. Sebb stated correctly that this approach is thread-hostile [1]. An alternative could be to make BeanHelper a non-static class which can be instantiated and configured per instance. This would be more flexible and would also simplify testing of client code (just pass in a mock object). The drawback is that clients now always would have to create an instance, so the API becomes slightly more verbose - in fact, most clients will probably never have the requirement to change the default bean factory. So, the question is, what do you prefer? The static approach like Object myBean = BeanHelper.createBean(...); or using an instance as in BeanHelper helper = new BeanHelper(myFactory); // or use no-args ctor for default factory Object myBean = helper.createBean(...); Personally, I would like the static method better as a user. Synchronizing access to the static factory field would seem to fix the problem unless I am missing something. Also, I would not expect lots of concurrent access to the getter/setter for this field in normal use cases , so the performance overhead of the sync would be immaterial. Having the setter there may also be a little easier for dependency injection. Phil TIA Oliver [1] https://issues.apache.org/jira/browse/CONFIGURATION-486 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.orgjavascript:; For additional commands, e-mail: dev-h...@commons.apache.orgjavascript:; - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org javascript:; For additional commands, e-mail: dev-h...@commons.apache.orgjavascript:; - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [convert] Automatic conversion based on proxies
I don't think CSV needs anything special to accommodate type conversion. The pattern I tried to introduce in the Commons Convert Getting Started section is one that works in any part of an application where conversion might be needed. So, instead of hard-coding conversions, the developer creates a facade that accommodates conversion anywhere in the program (not just in CSV). Instead of int columnInt = record.getValueAsInt(1); the developer would use Integer columnInt = Util.convertTo(record.getValue(1), Integer.class); By keeping type conversion separated, you can convert anything you encounter during development. Plus, this approach relieves CSV from being concerned with conversions - that is the developer's responsibility. If a developer used Commons Convert, then they could keep conversion details out of the code entirely and design external declarative conversions: file-reader input-file name=dailyForex format=CSV / field name=fromCurrency type=java.lang.String / field name=toCurrency type=java.lang.String / field name=conversionRate type=java.lang.Double / /input-file /file-reader -Adrian On 8/14/2013 7:54 AM, Gary Gregory wrote: On Tue, Aug 13, 2013 at 4:01 PM, Oliver Heger oliver.he...@oliver-heger.dewrote: Hi all, recently, there was a discussion about extending the [csv] interface to provide data conversions to different types. If such a use case is to be supported, what would be the best approach to integrate a library like [convert]? Well, the first step would be to release [Convert] 1.0 ;) It seems there would first need to be agreement that conversion belongs in [csv] in the first place, which is not the case for [CSV] 1.0. Personally, I'd like to focus on getting [CSV] 1.0 out the door and then adding features. It is good to talk about conversion now of course because it may affect the [CSV] APIs we provide. We do want to be backward compatible. Gary Doing all required conversions manually would probably mean a bunch of boilerplate code, wouldn't it? I had an idea how to automate this use case. Given an interface with a method T getValue(...); where T is some base type like String or Object. Now we want to provide other methods like int getValueAsInt(...); long getValueAsLong(...); ... If there is an extended interface with all getValueAsXXX() methods, couldn't the conversion be done by a proxy? The invocation handler would obtain the return type of the invoked method in order to determine the target class of the conversion. It would then call the basic getValue() method with the provided arguments, convert the result, and return it. This is the general idea, in practice probably some filtering would be needed to react only on certain method invocations. Do you think this use case is generic enough to support it in [convert] (e.g. by providing an abstract base class of an invocation handler and some convenience methods for creating proxy objects)? Oliver - 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] Prohibit creation of more than one iterator over a CSVParser?
The Iterator should contain a Parser, but not the other way around.
-Adrian
On 8/14/2013 11:22 AM, Benedikt Ritter wrote:
Thanks for the input. Now is the time to talk about this kind of stuff.
I understand Matt's proposal and it should be relatively easy to implement.
However I see Paul's point but don't know yet how to develop the API the
way he suggests.
Paul can your point be summed up as: Either expose an iterator or a parser
but not both?
What do others think? Sebb? Gary? Emmanuel?
This seems like one of the last issues on the road to 1.0
Benedikt
2013/8/13 Paul Benedict pbened...@apache.org
Perhaps we're going down the wrong path here. I think having an iterator()
and a parser conflict with each other. The former seems like a leaky
abstraction of the latter. I would propose the parser uses an iterator
internally, or there's an API to get an iterator from a data source (but
not expose the parser).
Paul
On Tue, Aug 13, 2013 at 9:00 AM, Matt Benson gudnabr...@gmail.com wrote:
One approach I think I've actually used at some point is for the same
class
to implement both Iterator and Iterable, implementing #iterator() as
`return this`. While it seems a little weird, it's really just a more
explicit reflection of what the current code is doing and so, at least in
this case, it seems to me justifiable. WDYT?
Matt
On Tue, Aug 13, 2013 at 8:39 AM, Benedikt Ritter brit...@apache.org
wrote:
We had that before but switched to Iterable to make it possible to use
CSVPaarser in foreach loops.
2013/8/13 Matt Benson gudnabr...@gmail.com
My thinking was more that CSVParser itself implements Iterator.
Matt
On Aug 13, 2013 2:59 AM, Benedikt Ritter brit...@apache.org
wrote:
Hi Matt,
2013/8/12 Matt Benson gudnabr...@gmail.com
As someone with no prior involvement with this component, and at
risk
of
being hit by the digital tomatoes of the group, this seems to
indicate
to
me that once a parser definition has been joined to a source of
input,
the
resulting object *is* the record iterator. If there's no way to
twist
that
into a comfortable API, I would tend to agree with Benedikt:
calling
#iterator() a second time should do something like triggering an
IllegalStateException().
No tomatoes, don't worry ;-) feedback is always welcome.
I'm not sure I understand what you're suggesting. Are you thinking
of
something like:
IteratorCSVRecord itr = CSVParser.parse(myCsvFile);
CSVParser has some features that go beyond the capabilities of the
Iterator() interface. For example one can ask the parser for the
current
line number in your input and the current record number (which may
not
be
the same for multi line records).
How about extending the Iterator interface?
CSVIterator itr = CSVParser.parse(myCsvFile);
and CSVIterator would look like:
public interface CSVIterator extends IteratorCSVRecord {
// call the cool CSVParser stuff goes here
}
But this wouldn't prevent more than one iterator over the same
source...
Benedikt
$0.02,
Matt
On Mon, Aug 12, 2013 at 4:43 PM, Gary Gregory
garydgreg...@gmail.com
wrote:
On Mon, Aug 12, 2013 at 3:26 PM, Benedikt Ritter
brit...@apache.org
wrote:
Hi,
I've added a new test to CSVParser test case that shows what
happens
if
CSVParser.iterator() is called twice [1].
This looks pretty strange to me. One iterator can eat up
records
of
the
other.
Would it be better to throw an exception if iterator() is
called
more
than
once?
Yeah, there is something odd about the current impl. Wouldn't
it
be
obvious
what can be done if there is an iterator ivar and the accessor
just
returns
it? It does not even have to be lazy initialized.
Gary
Benedikt
[1] http://svn.apache.org/r1513228
--
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
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
--
Cheers,
Paul
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CSV] Creating CSVParser instances
On 8/14/2013 1:10 PM, Emmanuel Bourg wrote: Le 14/08/2013 20:09, Benedikt Ritter a écrit : Every factory method an the constructor now take a CSVFormat. How about using CSVFormat.DEFAULT is null is passed as CSVFormat? Keeping null is better, using the default format might hide a bug in the calling code, and it could be difficult to figure it was caused by a null value if no NPE is thrown. Emmanuel Bourg I agree. Calling code needs to be explicit. Using the default would be appropriate for a no-arg constructor. -Adrian - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[CONVERT] Toward Release 1.0
In revision 1513175 I updated the code with the latest bug fixes. I can't deploy the site changes because the maven site:deploy target is broken - most likely due to recent changes to the deployment scripts. It worked fine the last time I used it. So, I need help from a maven guru to get it fixed. -Adrian - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1513173 - /commons/sandbox/convert/trunk/build.xml
The Convert devs use Ant. We are not accustomed to using Maven.
-Adrian
On 8/12/2013 11:34 AM, sebb wrote:
On 12 August 2013 18:45, Benedikt Ritter brit...@apache.org wrote:
2013/8/12 adri...@apache.org
Author: adrianc
Date: Mon Aug 12 15:47:17 2013
New Revision: 1513173
URL: http://svn.apache.org/r1513173
Log:
Fixed some build.xml errors, updated JUnit to 4.10.
JUnit 4.11 is the latest version.
Also, is the Ant build file really still needed?
Most Commons components only use Maven now.
[There are one or two that have particular requirements for Ant builds]
It's extra work to ensure that the Maven POM and build.xml remain in step.
Modified:
commons/sandbox/convert/trunk/build.xml
Modified: commons/sandbox/convert/trunk/build.xml
URL:
http://svn.apache.org/viewvc/commons/sandbox/convert/trunk/build.xml?rev=1513173r1=1513172r2=1513173view=diff
==
--- commons/sandbox/convert/trunk/build.xml (original)
+++ commons/sandbox/convert/trunk/build.xml Mon Aug 12 15:47:17 2013
@@ -116,7 +116,7 @@
/mkdir
javac destdir=${testclassesdir} deprecation=true debug=true
optimize=false excludes=**/package.html
src
-pathelement location=${basedir}/src/test
+pathelement location=${basedir}/src/test/java
/pathelement
/src
classpath
@@ -152,7 +152,7 @@
/javadoc
/target
target name=get-deps unless=noget depends=init
-get dest=${libdir}/junit-4.8.1.jar usetimestamp=true
ignoreerrors=true src=
http://www.ibiblio.org/maven/junit/jars/junit-4.8.1.jar;
+get dest=${libdir}/junit-4.10.jar usetimestamp=true
ignoreerrors=true src=
http://mirrors.ibiblio.org/maven2/junit/junit/4.10/junit-4.10.jar;
/get
!--
get dest=${libdir}/ant-1.5.jar usetimestamp=true
ignoreerrors=true src=http://www.ibiblio.org/maven/ant/jars/ant-1.5.jar
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
-
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: [CONVERT] Toward Release 1.0
Thanks! Running mvn clean site-deploy generates this error: [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 5:21.438s [INFO] Finished at: Mon Aug 12 12:49:09 PDT 2013 [INFO] Final Memory: 29M/74M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-scm-publish-plugin :1.0-beta-2:publish-scm (scm-publish) on project commons-convert: Failed to chec k-in files to SCM: The svn command failed. svn: E170001: Commit failed (details follow): [ERROR] svn: E170001: POST of '/repos/infra/!svn/me': authorization failed: Coul d not authenticate to server: rejected Basic challenge (https://svn.apache.org) [ERROR] - [Help 1] [ERROR] -Adrian On 8/12/2013 10:43 AM, Benedikt Ritter wrote: Hey, site publication has changed. Use the steps described on the website: http://commons.apache.org/site-publish.html Benedikt 2013/8/12 Adrian Crum adrian.c...@sandglass-software.com In revision 1513175 I updated the code with the latest bug fixes. I can't deploy the site changes because the maven site:deploy target is broken - most likely due to recent changes to the deployment scripts. It worked fine the last time I used it. So, I need help from a maven guru to get it fixed. -Adrian --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-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: [spam] Re: [CONVERT] Toward Release 1.0
I had to commit it manually. -Adrian On 8/12/2013 1:01 PM, Matt Benson wrote: Your account is likely locked out now. I just reset mine from a mvn site:stage build I did earlier today. ;) Matt On Mon, Aug 12, 2013 at 2:51 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: Thanks! Running mvn clean site-deploy generates this error: [INFO] --**--** [INFO] BUILD FAILURE [INFO] --**--** [INFO] Total time: 5:21.438s [INFO] Finished at: Mon Aug 12 12:49:09 PDT 2013 [INFO] Final Memory: 29M/74M [INFO] --**--** [ERROR] Failed to execute goal org.apache.maven.plugins:** maven-scm-publish-plugin :1.0-beta-2:publish-scm (scm-publish) on project commons-convert: Failed to chec k-in files to SCM: The svn command failed. svn: E170001: Commit failed (details follow): [ERROR] svn: E170001: POST of '/repos/infra/!svn/me': authorization failed: Coul d not authenticate to server: rejected Basic challenge ( https://svn.apache.org) [ERROR] - [Help 1] [ERROR] -Adrian On 8/12/2013 10:43 AM, Benedikt Ritter wrote: Hey, site publication has changed. Use the steps described on the website: http://commons.apache.org/**site-publish.htmlhttp://commons.apache.org/site-publish.html Benedikt 2013/8/12 Adrian Crum adrian.crum@sandglass-**software.comadrian.c...@sandglass-software.com In revision 1513175 I updated the code with the latest bug fixes. I can't deploy the site changes because the maven site:deploy target is broken - most likely due to recent changes to the deployment scripts. It worked fine the last time I used it. So, I need help from a maven guru to get it fixed. -Adrian --** --**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apac**he.orghttp://apache.org dev-unsubscribe@**commons.apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-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: [convert] String to Boolean converter
Yes, that would be a good change. The general goal of String conversions was to mimic the type's toString() and valueOf() methods, but there are some exceptions that are left over from OFBiz. I tried to remove the OFBiz-specific code when I ported the code to Commons, but I can see I missed a few spots. Another general goal was to make conversions bidirectional: Type A - Type B - Type A. So, the Boolean converters need some work. -Adrian On 8/5/2013 6:16 AM, Gary Gregory wrote: HI All: This is for the string to Boolean converter, but I suppose this applies to other converters. Would providing an alternate string for true be in the spirit of [convert]? What about for false? The current converter would be enhanced to support this, the alt strings would be provided in the ctor. What is the thinking WRT to validation? For example I want a boolean converter that throws an exception if the string is not true or false (ignoring case). Would this be more appropriate in a ValidatingStringToBooleanConverter instead of an extra setting in the ctor? Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [csv] accessing primitives and other record values
It might be best to suggest a facade that handles missing converters,
null or empty CSV fields, etc. That's why I suggested leaving the type
conversion to the applications programmer - we can't know what the
developer wants to do in those cases.
-Adrian
On 8/4/2013 6:53 PM, Gary Gregory wrote:
On Sat, Aug 3, 2013 at 1:31 PM, James Carman ja...@carmanconsulting.comwrote:
+1. We need to eat our own dog food when it makes sense.
Would this be the proper way to do things with [convert]?
import org.apache.commons.convert.ConversionException;
import org.apache.commons.convert.Converters;
public class CSVRecordConverter {
public CSVRecordConverter(CSVRecord record) {
super();
this.record = record;
}
private final CSVRecord record;
public boolean getBoolean(String name) throws ClassNotFoundException,
ConversionException {
return Converters.getConverter(String.class,
Boolean.class).convert(record.get(name)).booleanValue();
}
}
ClassNotFoundException seems really out of place here. I read If no
matching Converter is found, the method throws ClassNotFoundException.
It seems to me that a ConversionException would be better.
?
Gary
Our package
rename approach helps solve the jar hell issue, so adding dependencies
shouldn't be so frowned upon. Obviously if it's one little helper method
here and there we can copy the code if folks are really that averse to
dependencies.
On Saturday, August 3, 2013, Paul Benedict wrote:
If Convert and BeanUtils do the same thing, I think Commons needs to
figure
out how to solve this dilemma because duplicated functionality is usually
frowned upon here. For example, when Commons Lang began doing math, they
moved that to Commons Math (and the same thing happened for BeanUtils
from
Lang).
If Convert is to be released, I think BeanUtils should get some
refactoring
for a 2.0 release. They should harmonize but not duplicate functionality.
Paul
On Sat, Aug 3, 2013 at 11:58 AM, Gary Gregory garydgreg...@gmail.com
javascript:;
wrote:
On Sat, Aug 3, 2013 at 12:55 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
On 8/3/2013 9:49 AM, Gary Gregory wrote:
On Sat, Aug 3, 2013 at 12:10 PM, Adrian Crum
adrian.crum@sandglass-**software.com
adrian.c...@sandglass-software.com
wrote:
Inline...
On 8/3/2013 9:05 AM, Gary Gregory wrote:
On Sat, Aug 3, 2013 at 11:50 AM, Adrian Crum
adrian.crum@sandglass-**softwa**re.com http://software.com
adrian.crum@sandglass-**software.com
adrian.c...@sandglass-software.com
wrote:
Have you considered recommending Commons Convert?
No: it is unreleased. Are you willing to help polish it to 1.0?
Aside from a pending bug fix, the code is complete. The project
has
been
used by Apache OFBiz for years, so it is proven and stable. So, I
don't
know what additional steps are required to polish it.
There's no user manual or FAQ, the Javadoc is thin. How do you get
started?
I will try to build out the docs a little more. I think I need karma
to
edit the Convert Wiki - adrianc.
The docs should be in SVN IMO, just like most components.
Gary
More below.
Having an official release would be wonderful.
Yes: I'd like to eat our own dog food.
Gary
I agree that Java data type conversion is outside the scope of
CSV.
What about a CSVRecord wrapper that delegates to [convert]?
What would that look like? From my experience, hard-coding
conversions
is
not scalable. If an application needs to convert a CSV field to a
custom
type Foo, how will the wrapper accommodate that?
It would not for now. This is just about primitives or basic JRE
types
like
Number and Date (Calendar).
Gary
Gary
-Adrian
On 8/3/2013 8:36 AM, Gary Gregory wrote:
Hi All:
I recently added these CSVRecord APIs: getBoolean(String),
getInt(String),
getLong(String), getBigInteger(String).
Some people are OK with this, some consider this out of scope,
some
consider it not necessary for 1.0, some -1, some are worried
about
feature
creep (default values, Calendar, Date, List, and so on), some
think
the
Javadoc should be clearer.
At the very least I think we should document how to --
Cheers,
Paul
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [csv] accessing primitives and other record values
Have you considered recommending Commons Convert? I agree that Java data type conversion is outside the scope of CSV. -Adrian On 8/3/2013 8:36 AM, Gary Gregory wrote: Hi All: I recently added these CSVRecord APIs: getBoolean(String), getInt(String), getLong(String), getBigInteger(String). Some people are OK with this, some consider this out of scope, some consider it not necessary for 1.0, some -1, some are worried about feature creep (default values, Calendar, Date, List, and so on), some think the Javadoc should be clearer. At the very least I think we should document how to access or convert typed values. We could: - Document the new APIs, or remove them AND: - Document how to use another Commons API - Document how to use another (non Commons) API - Document how to do it all yourself - Create a CSVRecrord wrapper class that contains all the APIs where the implementation may or may not delegate to another Commons API. No matter what, it's pretty obvious that this conversion code is going to exist somewhere, in the user's app, in [csv] or someplace else. We should make a plan such that if we do not provide this feature in 1.0, we have a roadmap for our users. Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [csv] accessing primitives and other record values
Inline... On 8/3/2013 9:05 AM, Gary Gregory wrote: On Sat, Aug 3, 2013 at 11:50 AM, Adrian Crum adrian.c...@sandglass-software.com wrote: Have you considered recommending Commons Convert? No: it is unreleased. Are you willing to help polish it to 1.0? Aside from a pending bug fix, the code is complete. The project has been used by Apache OFBiz for years, so it is proven and stable. So, I don't know what additional steps are required to polish it. Having an official release would be wonderful. Yes: I'd like to eat our own dog food. Gary I agree that Java data type conversion is outside the scope of CSV. What about a CSVRecord wrapper that delegates to [convert]? What would that look like? From my experience, hard-coding conversions is not scalable. If an application needs to convert a CSV field to a custom type Foo, how will the wrapper accommodate that? Gary -Adrian On 8/3/2013 8:36 AM, Gary Gregory wrote: Hi All: I recently added these CSVRecord APIs: getBoolean(String), getInt(String), getLong(String), getBigInteger(String). Some people are OK with this, some consider this out of scope, some consider it not necessary for 1.0, some -1, some are worried about feature creep (default values, Calendar, Date, List, and so on), some think the Javadoc should be clearer. At the very least I think we should document how to access or convert typed values. We could: - Document the new APIs, or remove them AND: - Document how to use another Commons API - Document how to use another (non Commons) API - Document how to do it all yourself - Create a CSVRecrord wrapper class that contains all the APIs where the implementation may or may not delegate to another Commons API. No matter what, it's pretty obvious that this conversion code is going to exist somewhere, in the user's app, in [csv] or someplace else. We should make a plan such that if we do not provide this feature in 1.0, we have a roadmap for our users. Gary --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-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] accessing primitives and other record values
Actually, I picture it like this: Commons CSV does not contain any conversions, and data type conversions are left to the application developer. We can recommend Commons Convert. The applications developer is free to create any wrappers/facades necessary to connect the two. -Adrian On 8/3/2013 9:18 AM, Paul Benedict wrote: Adrian, the conversions would be configurable. At least that's how I envisioned it using existing BeanUtils functionality. Gary has a request our to me to demo that. On Aug 3, 2013 11:10 AM, Adrian Crum adrian.c...@sandglass-software.com wrote: Inline... On 8/3/2013 9:05 AM, Gary Gregory wrote: On Sat, Aug 3, 2013 at 11:50 AM, Adrian Crum adrian.crum@sandglass-**software.com adrian.c...@sandglass-software.com wrote: Have you considered recommending Commons Convert? No: it is unreleased. Are you willing to help polish it to 1.0? Aside from a pending bug fix, the code is complete. The project has been used by Apache OFBiz for years, so it is proven and stable. So, I don't know what additional steps are required to polish it. Having an official release would be wonderful. Yes: I'd like to eat our own dog food. Gary I agree that Java data type conversion is outside the scope of CSV. What about a CSVRecord wrapper that delegates to [convert]? What would that look like? From my experience, hard-coding conversions is not scalable. If an application needs to convert a CSV field to a custom type Foo, how will the wrapper accommodate that? Gary -Adrian On 8/3/2013 8:36 AM, Gary Gregory wrote: Hi All: I recently added these CSVRecord APIs: getBoolean(String), getInt(String), getLong(String), getBigInteger(String). Some people are OK with this, some consider this out of scope, some consider it not necessary for 1.0, some -1, some are worried about feature creep (default values, Calendar, Date, List, and so on), some think the Javadoc should be clearer. At the very least I think we should document how to access or convert typed values. We could: - Document the new APIs, or remove them AND: - Document how to use another Commons API - Document how to use another (non Commons) API - Document how to do it all yourself - Create a CSVRecrord wrapper class that contains all the APIs where the implementation may or may not delegate to another Commons API. No matter what, it's pretty obvious that this conversion code is going to exist somewhere, in the user's app, in [csv] or someplace else. We should make a plan such that if we do not provide this feature in 1.0, we have a roadmap for our users. Gary --** --**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apac**he.orghttp://apache.org dev-unsubscribe@**commons.apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-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] accessing primitives and other record values
The OFBiz community wanted to spin off the conversion framework to a separate project. I found the abandoned Commons Convert project and moved the code there. Someone suggested using Commons Convert for BeanUtils - so the duplication can be eliminated. -Adrian On 8/3/2013 9:42 AM, Paul Benedict wrote: I'll have to look into what Beanutils requires since it's been sometime I last directly dealt with it. I think it comes with basic Java conversions but everything can be configured as needed. I did not know about Commons Convert. Why two commons project that do the same thing? Paul On Sat, Aug 3, 2013 at 11:25 AM, Adrian Crum adrian.c...@sandglass-software.com wrote: Actually, I picture it like this: Commons CSV does not contain any conversions, and data type conversions are left to the application developer. We can recommend Commons Convert. The applications developer is free to create any wrappers/facades necessary to connect the two. -Adrian On 8/3/2013 9:18 AM, Paul Benedict wrote: Adrian, the conversions would be configurable. At least that's how I envisioned it using existing BeanUtils functionality. Gary has a request our to me to demo that. On Aug 3, 2013 11:10 AM, Adrian Crum adrian.crum@sandglass-** software.com adrian.c...@sandglass-software.com wrote: Inline... On 8/3/2013 9:05 AM, Gary Gregory wrote: On Sat, Aug 3, 2013 at 11:50 AM, Adrian Crum adrian.crum@sandglass-**softwa**re.com http://software.com adrian.crum@sandglass-**software.comadrian.c...@sandglass-software.com wrote: Have you considered recommending Commons Convert? No: it is unreleased. Are you willing to help polish it to 1.0? Aside from a pending bug fix, the code is complete. The project has been used by Apache OFBiz for years, so it is proven and stable. So, I don't know what additional steps are required to polish it. Having an official release would be wonderful. Yes: I'd like to eat our own dog food. Gary I agree that Java data type conversion is outside the scope of CSV. What about a CSVRecord wrapper that delegates to [convert]? What would that look like? From my experience, hard-coding conversions is not scalable. If an application needs to convert a CSV field to a custom type Foo, how will the wrapper accommodate that? Gary -Adrian On 8/3/2013 8:36 AM, Gary Gregory wrote: Hi All: I recently added these CSVRecord APIs: getBoolean(String), getInt(String), getLong(String), getBigInteger(String). Some people are OK with this, some consider this out of scope, some consider it not necessary for 1.0, some -1, some are worried about feature creep (default values, Calendar, Date, List, and so on), some think the Javadoc should be clearer. At the very least I think we should document how to access or convert typed values. We could: - Document the new APIs, or remove them AND: - Document how to use another Commons API - Document how to use another (non Commons) API - Document how to do it all yourself - Create a CSVRecrord wrapper class that contains all the APIs where the implementation may or may not delegate to another Commons API. No matter what, it's pretty obvious that this conversion code is going to exist somewhere, in the user's app, in [csv] or someplace else. We should make a plan such that if we do not provide this feature in 1.0, we have a roadmap for our users. Gary --**--** --** --**- To unsubscribe, e-mail: dev-unsubscribe@commons.apac**he.org http://apache.org** dev-unsubscribe@**commons.**apache.org http://commons.apache.org dev-unsubscribe@**commons.apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --** --**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apac**he.orghttp://apache.org dev-unsubscribe@**commons.apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-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] accessing primitives and other record values
On 8/3/2013 9:49 AM, Gary Gregory wrote: On Sat, Aug 3, 2013 at 12:10 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: Inline... On 8/3/2013 9:05 AM, Gary Gregory wrote: On Sat, Aug 3, 2013 at 11:50 AM, Adrian Crum adrian.crum@sandglass-**software.com adrian.c...@sandglass-software.com wrote: Have you considered recommending Commons Convert? No: it is unreleased. Are you willing to help polish it to 1.0? Aside from a pending bug fix, the code is complete. The project has been used by Apache OFBiz for years, so it is proven and stable. So, I don't know what additional steps are required to polish it. There's no user manual or FAQ, the Javadoc is thin. How do you get started? I will try to build out the docs a little more. I think I need karma to edit the Convert Wiki - adrianc. More below. Having an official release would be wonderful. Yes: I'd like to eat our own dog food. Gary I agree that Java data type conversion is outside the scope of CSV. What about a CSVRecord wrapper that delegates to [convert]? What would that look like? From my experience, hard-coding conversions is not scalable. If an application needs to convert a CSV field to a custom type Foo, how will the wrapper accommodate that? It would not for now. This is just about primitives or basic JRE types like Number and Date (Calendar). Gary Gary -Adrian On 8/3/2013 8:36 AM, Gary Gregory wrote: Hi All: I recently added these CSVRecord APIs: getBoolean(String), getInt(String), getLong(String), getBigInteger(String). Some people are OK with this, some consider this out of scope, some consider it not necessary for 1.0, some -1, some are worried about feature creep (default values, Calendar, Date, List, and so on), some think the Javadoc should be clearer. At the very least I think we should document how to access or convert typed values. We could: - Document the new APIs, or remove them AND: - Document how to use another Commons API - Document how to use another (non Commons) API - Document how to do it all yourself - Create a CSVRecrord wrapper class that contains all the APIs where the implementation may or may not delegate to another Commons API. No matter what, it's pretty obvious that this conversion code is going to exist somewhere, in the user's app, in [csv] or someplace else. We should make a plan such that if we do not provide this feature in 1.0, we have a roadmap for our users. Gary --** --**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apac**he.orghttp://apache.org dev-unsubscribe@**commons.apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-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] accessing primitives and other record values
I am working on getting the bug fixes committed today. I will also include some more JavaDocs - hopefully that will help. If anyone wants to improve things further, they are welcome to do so. -Adrian On 8/3/2013 9:17 AM, James Carman wrote: On Sat, Aug 3, 2013 at 12:05 PM, Gary Gregory garydgreg...@gmail.com wrote: No: it is unreleased. Are you willing to help polish it to 1.0? I'm willing! The current API might be a bit verbose. We can figure out the bound types at runtime to determine the source/target types. That would streamline the API quite a bit. - 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: [CHAIN] Why does ConextMap extend ConcurrentHashMap instead of delegating to a Map?
I have always preferred the has-a approach over the is-a approach. It makes things easier to refactor down the road. -Adrian On 6/24/2013 7:30 PM, Benedikt Ritter wrote: Hi, I just wonder why ContextMap inherits from ConcurrentHashMap. This seems like an unnecessary restriction. The context interface makes explicit, that implementations do not have to be thread safe. Beside that we loose all thread safety a ConcurrentHashMap provides with our not-so-thread-safe implementations in ContextMap and ContextBase. I'd suggest to switch from an inheritance based approach to a delegation based approach. That leaves users with the liberty to choose what ever underlying Map implementation they like for their context. WDYT? Benedikt - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CSV] change line number from 0-based to 1-based
Maybe the method could be named better, something like ExtendedBufferedReader.getCurrentLineNumber() - which would be different than total lines processed. -Adrian On 5/7/2013 11:05 AM, sebb wrote: I've been looking at it further and there is an issue with 1-based counting. The line number currently counts the number of EOLs seen. This means it is currently accurate for total line count (which a 1-based system would not be) and is accurate for any completed records. It's only during processing of a line (before EOL is reached) that the count is off by one. I noticed that when I tested an invalid parse. One way round this would be to adjust the count when generating the IOException. e.g. if there are spurious characters before EOL it's obvious that one needs to add 1. I suspect it might be a bit tricky / more expensive to increment the line number only at the start of a line. Needs further work, which is why I started by just correcting the Javadoc to agree with the code. On 7 May 2013 08:00, Benedikt Ritter brit...@apache.org wrote: 2013/5/6 Gary Gregory garydgreg...@gmail.com On Mon, May 6, 2013 at 5:49 PM, sebb seb...@gmail.com wrote: The line number returned by ExtendedBufferedReader.getLineNumber() currently starts at zero, so an error in the first line in the file is reported as being in line 0. There does not seem to be any good reason for using a zero-based line number, so I would like to change it to 1-based. Some tests will need to be fixed. WDYT? +1 Gary Makes sense to me too. - 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 - 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] change line number from 0-based to 1-based
From my perspective, it should be fairly easy to make it clear... 1. File is opened, but not processed. Current line number = 1, total lines processed = 0, records processed = 0. 2. First line is processed. Current line number = 2, lines processed = 1, records processed = 0. 3. Second line is processed, reached end of record. Current line number = 3, lines processed = 2, records processed = 1. -Adrian On 5/7/2013 12:08 PM, sebb wrote: On 7 May 2013 11:36, Adrian Crum adrian.c...@sandglass-software.com wrote: Maybe the method could be named better, something like ExtendedBufferedReader.getCurrentLineNumber() - which would be different than total lines processed. Indeed, but at present there is no method which accurately reports the current line number for all situations. The method getLineNumber() currently reports the EOL count, which is the number of (complete) lines seen. The name is ambiguous. I don't think it is worth renaming until the design is sorted out. -Adrian On 5/7/2013 11:05 AM, sebb wrote: I've been looking at it further and there is an issue with 1-based counting. The line number currently counts the number of EOLs seen. This means it is currently accurate for total line count (which a 1-based system would not be) and is accurate for any completed records. It's only during processing of a line (before EOL is reached) that the count is off by one. I noticed that when I tested an invalid parse. One way round this would be to adjust the count when generating the IOException. e.g. if there are spurious characters before EOL it's obvious that one needs to add 1. I suspect it might be a bit tricky / more expensive to increment the line number only at the start of a line. Needs further work, which is why I started by just correcting the Javadoc to agree with the code. On 7 May 2013 08:00, Benedikt Ritter brit...@apache.org wrote: 2013/5/6 Gary Gregory garydgreg...@gmail.com On Mon, May 6, 2013 at 5:49 PM, sebb seb...@gmail.com wrote: The line number returned by ExtendedBufferedReader.getLineNumber() currently starts at zero, so an error in the first line in the file is reported as being in line 0. There does not seem to be any good reason for using a zero-based line number, so I would like to change it to 1-based. Some tests will need to be fixed. WDYT? +1 Gary Makes sense to me too. - 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 - 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1477592 - in /commons/proper/codec/trunk/src: changes/changes.xml main/java/org/apache/commons/codec/language/Metaphone.java
On 4/30/2013 1:32 PM, ggreg...@apache.org wrote: Author: ggregory Date: Tue Apr 30 12:32:24 2013 New Revision: 1477592 URL: http://svn.apache.org/r1477592 Log: [CODEC-170] Link broken in Metaphone Javadoc. Modified: commons/proper/codec/trunk/src/changes/changes.xml commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/language/Metaphone.java Modified: commons/proper/codec/trunk/src/changes/changes.xml URL: http://svn.apache.org/viewvc/commons/proper/codec/trunk/src/changes/changes.xml?rev=1477592r1=1477591r2=1477592view=diff == --- commons/proper/codec/trunk/src/changes/changes.xml (original) +++ commons/proper/codec/trunk/src/changes/changes.xml Tue Apr 30 12:32:24 2013 @@ -43,7 +43,7 @@ The action type attribute can be add,u /properties body release version=1.9 date=TBA description=Feature and fix release. - action dev=... type=fix issue=CODEC-NNN.../action + action dev=ggregory type=fix issue=CODEC-170 description=Link broken in Metaphone Javadoc due-to=Ron Wheeler, Henri Yandell/ /release release version=1.8 date=19 April 2013 description=Feature and fix release. Requires a minimum of Java 1.6 action dev=ggregory type=add issue=CODEC-168 due-to=Daniel CassidyAdd DigestUtils.updateDigest(MessageDigest, InputStream)./action Modified: commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/language/Metaphone.java URL: http://svn.apache.org/viewvc/commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/language/Metaphone.java?rev=1477592r1=1477591r2=1477592view=diff == --- commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/language/Metaphone.java (original) +++ commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/language/Metaphone.java Tue Apr 30 12:32:24 2013 @@ -29,8 +29,13 @@ import org.apache.commons.codec.StringEn * CITEHanging on the Metaphone/CITE by CITELawrence Philips/CITE in CITEComputer Language of Dec. 1990, * p 39./CITE * p - * Note, that this does not match the algorithm that ships with PHP, or the algorithm found in the Perl - * a href=http://search.cpan.org/~mschwern/Text-Metaphone-1.96/Metaphone.pm;Text:Metaphone-1.96/a. + * Note, that this does not match the algorithm that ships with PHP, or the algorithm found in the Perl implemenations: Spelling error in that last line. -Adrian - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CSV] Should the Builder API be optional?
True. Users are free to create their own facade to make object construction easier. -Adrian On 4/9/2013 6:22 AM, Gary Gregory wrote: WRT org.apache.commons.csv.CSVFormat.CSVFormat(char, Character, Quote, Character, Character, boolean, boolean, String, String, String[]) There does not seem to be a good reason why this is not public. The only argument I've heard is that some people do not like to use long ctors. But so what? If we make it public, users have the choice to the the whole fluent builder API or not. Thoughts? Gary On Mon, Apr 8, 2013 at 7:15 PM, Gary Gregory garydgreg...@gmail.com wrote: I would be ok with making the parser and format ctors public. What else? I agree that we should not force force folks into an API pattern but here it's not a big API at least. Gary On Apr 8, 2013, at 17:02, Emmanuel Bourg ebo...@apache.org wrote: Le 08/04/2013 22:39, Gary Gregory a écrit : But that's the price for immutability for some of these objects. Not sure, we already achieved immutability last year without paying this price: http://svn.apache.org/repos/asf/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java?p=1305548 This design was sacrified for the sake of implementing a by the book builder pattern that brings no real benefit in term of usability. It's just a useless layer of complexity. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Cobertura and Parent POM
Thank you for working on this. The original proposal was to replace Cobertura with something else. I asked that the sub projects have an option to use whatever reporting tool they want. So, it would be fine if some other reporting tool was the default as long as sub projects can use something else. -Adrian On 4/4/2013 9:03 PM, sebb wrote: CP 28 moved Cobertura to a profile called reporting. The profile was activated by default, but could be disabled by using -DskipReports=true or -P!reporting IIRC, the idea was to move expensive (long-running) reports to a profile that could be disabled if necessary. However Cobertura causes problems with some projects, and the project seems to be unmaintained, so perhaps it would be sensible to disable Cobertura by default. In which case the profile and property should be renamed to reflect the fact that it only affects Cobertura. Possibly even drop Cobertura entirely from the parent POM. However, I think it is important that some code coverage tool is used. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1461134 - in /commons/proper/csv/trunk/src: main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
I like the idea of improving the JavaDoc. The DEFAULT field was very intuitive. -Adrian On 3/26/2013 2:14 PM, Gary Gregory wrote: On Tue, Mar 26, 2013 at 10:06 AM, Emmanuel Bourg ebo...@apache.org wrote: Le 26/03/2013 14:58, ggreg...@apache.org a écrit : -public static final CSVFormat DEFAULT = // TODO rename to something more meaningful +public static final CSVFormat RFC4180_EMPTY_LINES = My opinion, from the Ease of Use Department, when I read the Javadoc and see DEFAULT I understand immediately that's what I should probably use. With RFC4180_EMPTY_LINES I have no idea what this means (and probably scared that I'll have to read a RFC to understand it). Then we need to make the Javadoc better. DEFAULT means nothing because it is arbitrary as exemplified by the Javadoc: it's the RFC with empty lines, but it could be anything we decide, which is unhelpful and could change. If you read RFC4180_EMPTY_LINES or RFC4180_THIS_AND_THAT, you know as a user that it is precise and quite unlikely to change, whereas DEFAULT could change from RFC and this or RFC and this and that... Gary Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CSV] Extract interfaces?
On 3/23/2013 12:59 PM, Thomas Neidhart wrote: On 03/23/2013 12:41 PM, Benedikt Ritter wrote: Hi, while looking through the code, I was asking myself why we expose implementation classes. Wouldn't it be better to extract interfaces from CSVParser, CSVPrinter and CSVRecord? At least for the CSVRecord it would make sense because users cannot create CSVRecord instances. Why binding them to a concrete implementation? Since CSVParser und CSVPrinter can only be created using the default ctor, users would have to write something like (and though still defining a dependency to the concrete implemenation): CSVPrinter printer = new DefaultCSVPrinter(in, format); It would even make sense to extract an Interface for Lexer and CSVLexer although it is only used internally. Having an abstract class (Lexer) that defines a abstract method, that is not used in one of the other methods, but just defines an interface feels strange. And if we decide to expose the lexer, so that users can plugin their own lexer implementations (for what ever reason...) we would be set up for this. I think it is important to make things not more complicated than necessary. If there will be only one implementation of this interface you do not gain anything by splitting it up. In math we merged many of this interface/implementation constructs back into a single class. If there is a need to alter/tweak the behavior of a class you can still subclass it, I guess. Thomas I agree. Interfaces would make sense if you expected to have many different implementations. -Adrian - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CSV] Finishing v1.0
The CSV site is very confusing: 1. The nightly build is not current. 2. The JavaDoc (latest) link points to an API that does not match the latest API. -Adrian On 3/20/2013 8:59 AM, Adrian Crum wrote: Okay, that looks better. -Adrian On 3/20/2013 8:52 AM, Benedikt Ritter wrote: That build is dated 30-Jul-2007. Please have a look at trunk in SVN ;-) Benedikt 2013/3/20 Adrian Crum adrian.c...@sandglass-software.com I grabbed the latest build: http://people.apache.org/** builds/commons/nightly/**commons-csv/http://people.apache.org/builds/commons/nightly/commons-csv/ -Adrian On 3/20/2013 8:43 AM, Benedikt Ritter wrote: Adrian, you've lost me. What CSVStrategy are you talking about? Are you looking at https://svn.apache.org/repos/**asf/commons/proper/csv/trunkhttps://svn.apache.org/repos/asf/commons/proper/csv/trunk? 2013/3/20 Adrian Crum adrian.crum@sandglass-**software.comadrian.c...@sandglass-software.com There is a part of the API that I don't like - the CSVStrategy class is mutable. I can't imagine a file's strategy changing mid-file, so from my perspective the class should be immutable. Plus, the previous version used a builder pattern that I liked. -Adrian On 3/19/2013 6:43 PM, sebb wrote: On 19 March 2013 18:38, Benedikt Ritter brit...@apache.org wrote: How do you feel about postponing some of the improvement tickets until after the initial release? Is this possible with commons release policy or do we have to resolve all open issues? As far as I'm concerned, Improvement tickets can be postponed. IMO the only items that must be fixed are regressions (not possible for first release of course). Also if there is new code with a bad API, that needs to be fixed before first release as it may be impossible to fix later without causing lots of trouble, Benedikt 2013/3/19 Adrian Crum adrian.crum@sandglass-**softw**are.comhttp://software.com adrian.crum@sandglass-**software.comadrian.c...@sandglass-software.com I would be interested in helping too. -Adrian On 3/19/2013 12:53 PM, Gary Gregory wrote: I am interested in seeing it through a 1.0. Let's make sure we like the API... Gary On Tue, Mar 19, 2013 at 8:39 AM, Benedikt Ritter brit...@apache.org wrote: Hi all, we have this request [1] from the Any23 community regarding [csv]. I believe we can help them in several ways. The first thing to do would be to request a git mirror of [csv] from infra, so that Any23 can use the latest trunk by cloning that mirror. The second is to finish work on [csv] and push out a 1.0 soon. When we were working on [csv] last year there were a few unresolved issues, like improving performance and general refactoring. Also we have 6 unresolved bugs. I'd like you to get involved in reviewing the state of the API. Is the API in a state that can be shipped? Does the API allow us to increase performances without breaking BC after releasing 1.0. My goal would be to fix the 6 open bugs and post pone improvements for 1.1. People are waiting for this release (remember this issue with solr [2]? They also want this library to be released!) Who has some spare time to help me with this? Regards, Benedikt [1] http://markmail.org/message/**ylwdhkth2t2kjek4http://markmail.org/message/ylwdhkth2t2kjek4 http://**markmail.org/message/ylwdhkth2t2kjek4http://markmail.org/message/**ylwdhkth2t2kjek4 http://**markmail.org/**message/**ylwdhkth2t2kjek4http://markmail.org/message/**ylwdhkth2t2kjek4 htt**p://markmail.org/message/**ylwdhkth2t2kjek4http://markmail.org/message/ylwdhkth2t2kjek4 [2] https://issues.apache.org/**jira/browse/SOLR-3204https://issues.apache.org/jira/browse/SOLR-3204 https://**issues.apache.org/**jira/**browse/SOLR-3204https://issues.apache.org/**jira/browse/SOLR-3204 https://**issues.apache.org/**jira/browse/**SOLR-3204http://issues.apache.org/jira/browse/**SOLR-3204 https:**//issues.apache.org/jira/**browse/SOLR-3204https://issues.apache.org/jira/browse/SOLR-3204 -- http://people.apache.org/~**britter/http://people.apache.org/~britter/ http://people.apache.**org/~**britter/http://people.apache.org/~**britter/ http://people.apache.**org/~**britter/http://people.apache.** org/~britter/ http://people.apache.org/~britter/ http://www.systemoutprintln.**de/ http://www.systemoutprintln. de/ http://www.systemoutprintln.**de/http://www.systemoutprintln.de/ http://twitter.com/**BenediktRitterhttp://twitter.com/BenediktRitter http://twitter.**com/**BenediktRitterhttp://twitter.com/**BenediktRitter http://twitter.com/BenediktRitterhttp://twitter.com/**BenediktRitter http://twitter.**com/BenediktRitterhttp://twitter.com/BenediktRitter http://github.com/britter --**--** --** --**- To unsubscribe, e-mail: dev-unsubscribe@commons.apac**he.org http://apache.org** dev-unsubscribe@**commons
Re: [CSV] Finishing v1.0
Running mvn site generates an error: [ERROR] BUILD ERROR [INFO] [INFO] Error during page generation Embedded error: Error rendering Maven report: org.dom4j.DocumentFactory cannot b e cast to org.dom4j.DocumentFactory Nested exception: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory [INFO] [INFO] For more information, run Maven with the -e switch [INFO] -Adrian On 3/21/2013 9:38 AM, Adrian Crum wrote: The CSV site is very confusing: 1. The nightly build is not current. 2. The JavaDoc (latest) link points to an API that does not match the latest API. -Adrian On 3/20/2013 8:59 AM, Adrian Crum wrote: Okay, that looks better. -Adrian On 3/20/2013 8:52 AM, Benedikt Ritter wrote: That build is dated 30-Jul-2007. Please have a look at trunk in SVN ;-) Benedikt 2013/3/20 Adrian Crum adrian.c...@sandglass-software.com I grabbed the latest build: http://people.apache.org/** builds/commons/nightly/**commons-csv/http://people.apache.org/builds/commons/nightly/commons-csv/ -Adrian On 3/20/2013 8:43 AM, Benedikt Ritter wrote: Adrian, you've lost me. What CSVStrategy are you talking about? Are you looking at https://svn.apache.org/repos/**asf/commons/proper/csv/trunkhttps://svn.apache.org/repos/asf/commons/proper/csv/trunk? 2013/3/20 Adrian Crum adrian.crum@sandglass-**software.comadrian.c...@sandglass-software.com There is a part of the API that I don't like - the CSVStrategy class is mutable. I can't imagine a file's strategy changing mid-file, so from my perspective the class should be immutable. Plus, the previous version used a builder pattern that I liked. -Adrian On 3/19/2013 6:43 PM, sebb wrote: On 19 March 2013 18:38, Benedikt Ritter brit...@apache.org wrote: How do you feel about postponing some of the improvement tickets until after the initial release? Is this possible with commons release policy or do we have to resolve all open issues? As far as I'm concerned, Improvement tickets can be postponed. IMO the only items that must be fixed are regressions (not possible for first release of course). Also if there is new code with a bad API, that needs to be fixed before first release as it may be impossible to fix later without causing lots of trouble, Benedikt 2013/3/19 Adrian Crum adrian.crum@sandglass-**softw**are.comhttp://software.com adrian.crum@sandglass-**software.comadrian.c...@sandglass-software.com I would be interested in helping too. -Adrian On 3/19/2013 12:53 PM, Gary Gregory wrote: I am interested in seeing it through a 1.0. Let's make sure we like the API... Gary On Tue, Mar 19, 2013 at 8:39 AM, Benedikt Ritter brit...@apache.org wrote: Hi all, we have this request [1] from the Any23 community regarding [csv]. I believe we can help them in several ways. The first thing to do would be to request a git mirror of [csv] from infra, so that Any23 can use the latest trunk by cloning that mirror. The second is to finish work on [csv] and push out a 1.0 soon. When we were working on [csv] last year there were a few unresolved issues, like improving performance and general refactoring. Also we have 6 unresolved bugs. I'd like you to get involved in reviewing the state of the API. Is the API in a state that can be shipped? Does the API allow us to increase performances without breaking BC after releasing 1.0. My goal would be to fix the 6 open bugs and post pone improvements for 1.1. People are waiting for this release (remember this issue with solr [2]? They also want this library to be released!) Who has some spare time to help me with this? Regards, Benedikt [1] http://markmail.org/message/**ylwdhkth2t2kjek4http://markmail.org/message/ylwdhkth2t2kjek4 http://**markmail.org/message/ylwdhkth2t2kjek4http://markmail.org/message/**ylwdhkth2t2kjek4 http://**markmail.org/**message/**ylwdhkth2t2kjek4http://markmail.org/message/**ylwdhkth2t2kjek4 htt**p://markmail.org/message/**ylwdhkth2t2kjek4http://markmail.org/message/ylwdhkth2t2kjek4 [2] https://issues.apache.org/**jira/browse/SOLR-3204https://issues.apache.org/jira/browse/SOLR-3204 https://**issues.apache.org/**jira/**browse/SOLR-3204https://issues.apache.org/**jira/browse/SOLR-3204 https://**issues.apache.org/**jira/browse/**SOLR-3204http://issues.apache.org/jira/browse/**SOLR-3204 https:**//issues.apache.org/jira/**browse/SOLR-3204https://issues.apache.org/jira/browse/SOLR-3204 -- http://people.apache.org/~**britter/http://people.apache.org/~britter/ http://people.apache.**org/~**britter/http://people.apache.org/~**britter/ http://people.apache.**org/~**britter/http://people.apache.** org/~britter/ http://people.apache.org/~britter/ http
Re: [CSV] Problems building the page Was: [CSV] Finishing v1.0
I upgraded to Maven 3.0.5 and the problem was solved. Thanks! -Adrian On 3/21/2013 2:48 PM, Gary Gregory wrote: My recommendation is to run with: Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 08:51:28-0500) Maven home: C:\Java\apache-maven-3.0.5\bin\.. Java version: 1.6.0_39, vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\jdk1.6.0_39\jre This should not matter: Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Gary On Thu, Mar 21, 2013 at 7:14 AM, Benedikt Ritter brit...@apache.org wrote: 2013/3/21 Adrian Crum adrian.c...@sandglass-software.com Running mvn site generates an error: [ERROR] BUILD ERROR [INFO] --**--** [INFO] Error during page generation Embedded error: Error rendering Maven report: org.dom4j.DocumentFactory cannot b e cast to org.dom4j.DocumentFactory Nested exception: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory [INFO] --**--** [INFO] For more information, run Maven with the -e switch [INFO] --**--** -Adrian Hi Adrian, that is strange. I can not reproduce this. Can you please send the output of mvn -v? Regarding the live page of csv: it has been published a while ago and since nothing was released till then, it is outdated. I agree with you, that we should probably keep it up to date, but don't know how to do this. Can some one please help out here? Regards, Benedikt On 3/21/2013 9:38 AM, Adrian Crum wrote: The CSV site is very confusing: 1. The nightly build is not current. 2. The JavaDoc (latest) link points to an API that does not match the latest API. -Adrian On 3/20/2013 8:59 AM, Adrian Crum wrote: Okay, that looks better. -Adrian On 3/20/2013 8:52 AM, Benedikt Ritter wrote: That build is dated 30-Jul-2007. Please have a look at trunk in SVN ;-) Benedikt 2013/3/20 Adrian Crum adrian.crum@sandglass-**software.com adrian.c...@sandglass-software.com I grabbed the latest build: http://people.apache.org/** builds/commons/nightly/commons-csv/http://people.** apache.org/builds/commons/**nightly/commons-csv/ http://people.apache.org/builds/commons/nightly/commons-csv/ -Adrian On 3/20/2013 8:43 AM, Benedikt Ritter wrote: Adrian, you've lost me. What CSVStrategy are you talking about? Are you looking at https://svn.apache.org/repos/*** *asf/commons/proper/csv/trunk https://svn.apache.org/repos/**asf/commons/proper/csv/trunk **https://svn.apache.org/repos/**asf/commons/proper/csv/trunk https://svn.apache.org/repos/asf/commons/proper/csv/trunk ? 2013/3/20 Adrian Crum adrian.crum@sandglass-**softw**are.com http://software.com adrian.crum@sandglass-**software.com adrian.c...@sandglass-software.com There is a part of the API that I don't like - the CSVStrategy class is mutable. I can't imagine a file's strategy changing mid-file, so from my perspective the class should be immutable. Plus, the previous version used a builder pattern that I liked. -Adrian On 3/19/2013 6:43 PM, sebb wrote: On 19 March 2013 18:38, Benedikt Ritter brit...@apache.org wrote: How do you feel about postponing some of the improvement tickets until after the initial release? Is this possible with commons release policy or do we have to resolve all open issues? As far as I'm concerned, Improvement tickets can be postponed. IMO the only items that must be fixed are regressions (not possible for first release of course). Also if there is new code with a bad API, that needs to be fixed before first release as it may be impossible to fix later without causing lots of trouble, Benedikt 2013/3/19 Adrian Crum adrian.crum@sandglass-softw**are.com http://**software.com http://software.com adrian.crum@sandglass-**softw**are.com http://software.com adrian.crum@sandglass-**software.com adrian.c...@sandglass-software.com I would be interested in helping too. -Adrian On 3/19/2013 12:53 PM, Gary Gregory wrote: I am interested in seeing it through a 1.0. Let's make sure we like the API... Gary On Tue, Mar 19, 2013 at 8:39 AM, Benedikt Ritter brit...@apache.org wrote: Hi all, we have this request [1] from the Any23 community regarding [csv]. I believe we can help them in several ways. The first thing to do would be to request a git mirror of [csv] from infra, so that Any23 can use the latest trunk by cloning that mirror. The second is to finish work on [csv] and push out a 1.0 soon. When we were working on [csv] last year there were a few unresolved issues, like improving performance and general refactoring. Also we have 6 unresolved bugs. I'd like you to get involved in reviewing the state of the API. Is the API in a state that can be shipped? Does the API
Re: [CSV] Problems building the page Was: [CSV] Finishing v1.0
lol - NOW you ask me. I think it was 2.2. -Adrian On 3/21/2013 4:12 PM, Gary Gregory wrote: What version did you use before? Gary On Thu, Mar 21, 2013 at 11:35 AM, Adrian Crum adrian.c...@sandglass-software.com wrote: I upgraded to Maven 3.0.5 and the problem was solved. Thanks! -Adrian On 3/21/2013 2:48 PM, Gary Gregory wrote: My recommendation is to run with: Apache Maven 3.0.5 (**r01de14724cdef164cd33c7c8c2fe1**55faf9602da; 2013-02-19 08:51:28-0500) Maven home: C:\Java\apache-maven-3.0.5\**bin\.. Java version: 1.6.0_39, vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\jdk1.6.0_39\jre This should not matter: Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Gary On Thu, Mar 21, 2013 at 7:14 AM, Benedikt Ritter brit...@apache.org wrote: 2013/3/21 Adrian Crum adrian.crum@sandglass-**software.comadrian.c...@sandglass-software.com Running mvn site generates an error: [ERROR] BUILD ERROR [INFO] --** --** [INFO] Error during page generation Embedded error: Error rendering Maven report: org.dom4j.DocumentFactory cannot b e cast to org.dom4j.DocumentFactory Nested exception: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory [INFO] --** --** [INFO] For more information, run Maven with the -e switch [INFO] --** --** -Adrian Hi Adrian, that is strange. I can not reproduce this. Can you please send the output of mvn -v? Regarding the live page of csv: it has been published a while ago and since nothing was released till then, it is outdated. I agree with you, that we should probably keep it up to date, but don't know how to do this. Can some one please help out here? Regards, Benedikt On 3/21/2013 9:38 AM, Adrian Crum wrote: The CSV site is very confusing: 1. The nightly build is not current. 2. The JavaDoc (latest) link points to an API that does not match the latest API. -Adrian On 3/20/2013 8:59 AM, Adrian Crum wrote: Okay, that looks better. -Adrian On 3/20/2013 8:52 AM, Benedikt Ritter wrote: That build is dated 30-Jul-2007. Please have a look at trunk in SVN ;-) Benedikt 2013/3/20 Adrian Crum adrian.crum@sandglass-**softw**are.comhttp://software.com adrian.crum@sandglass-**software.comadrian.c...@sandglass-software.com I grabbed the latest build: http://people.apache.org/** builds/commons/nightly/**commons-csv/http://people.** apache.org/builds/commons/nightly/commons-csv/http://apache.org/builds/commons/**nightly/commons-csv/ http://people.apache.org/**builds/commons/nightly/**commons-csv/http://people.apache.org/builds/commons/nightly/commons-csv/ -Adrian On 3/20/2013 8:43 AM, Benedikt Ritter wrote: Adrian, you've lost me. What CSVStrategy are you talking about? Are you looking at https://svn.apache.org/repos/*https://svn.apache.org/repos/*** *asf/commons/proper/csv/trunk https://svn.apache.org/repos/asf/commons/proper/csv/trunkhttps://svn.apache.org/repos/**asf/commons/proper/csv/trunk **https://svn.apache.org/**repos/**asf/commons/proper/**csv/trunkhttps://svn.apache.org/repos/**asf/commons/proper/csv/trunk https://svn.apache.org/repos/**asf/commons/proper/csv/trunkhttps://svn.apache.org/repos/asf/commons/proper/csv/trunk ? 2013/3/20 Adrian Crum adrian.crum@sandglass-softw**are.com http://software.com adrian.crum@sandglass-**softw**are.com http://software.com adrian.crum@sandglass-**software.comadrian.c...@sandglass-software.com There is a part of the API that I don't like - the CSVStrategy class is mutable. I can't imagine a file's strategy changing mid-file, so from my perspective the class should be immutable. Plus, the previous version used a builder pattern that I liked. -Adrian On 3/19/2013 6:43 PM, sebb wrote: On 19 March 2013 18:38, Benedikt Ritter brit...@apache.org wrote: How do you feel about postponing some of the improvement tickets until after the initial release? Is this possible with commons release policy or do we have to resolve all open issues? As far as I'm concerned, Improvement tickets can be postponed. IMO the only items that must be fixed are regressions (not possible for first release of course). Also if there is new code with a bad API, that needs to be fixed before first release as it may be impossible to fix later without causing lots of trouble, Benedikt 2013/3/19 Adrian Crum adrian.crum@sandglass-**softw** are.com http://**software.com http://software.com adrian.crum@sandglass-softw**are.com http://software.com adrian.crum@sandglass-**softwa**re.com http://software.com adrian.crum@sandglass-**software.comadrian.c...@sandglass-software.com I would be interested in helping too
Re: [CSV] Finishing v1.0
There is a part of the API that I don't like - the CSVStrategy class is mutable. I can't imagine a file's strategy changing mid-file, so from my perspective the class should be immutable. Plus, the previous version used a builder pattern that I liked. -Adrian On 3/19/2013 6:43 PM, sebb wrote: On 19 March 2013 18:38, Benedikt Ritter brit...@apache.org wrote: How do you feel about postponing some of the improvement tickets until after the initial release? Is this possible with commons release policy or do we have to resolve all open issues? As far as I'm concerned, Improvement tickets can be postponed. IMO the only items that must be fixed are regressions (not possible for first release of course). Also if there is new code with a bad API, that needs to be fixed before first release as it may be impossible to fix later without causing lots of trouble, Benedikt 2013/3/19 Adrian Crum adrian.c...@sandglass-software.com I would be interested in helping too. -Adrian On 3/19/2013 12:53 PM, Gary Gregory wrote: I am interested in seeing it through a 1.0. Let's make sure we like the API... Gary On Tue, Mar 19, 2013 at 8:39 AM, Benedikt Ritter brit...@apache.org wrote: Hi all, we have this request [1] from the Any23 community regarding [csv]. I believe we can help them in several ways. The first thing to do would be to request a git mirror of [csv] from infra, so that Any23 can use the latest trunk by cloning that mirror. The second is to finish work on [csv] and push out a 1.0 soon. When we were working on [csv] last year there were a few unresolved issues, like improving performance and general refactoring. Also we have 6 unresolved bugs. I'd like you to get involved in reviewing the state of the API. Is the API in a state that can be shipped? Does the API allow us to increase performances without breaking BC after releasing 1.0. My goal would be to fix the 6 open bugs and post pone improvements for 1.1. People are waiting for this release (remember this issue with solr [2]? They also want this library to be released!) Who has some spare time to help me with this? Regards, Benedikt [1] http://markmail.org/message/**ylwdhkth2t2kjek4http://markmail.org/message/ylwdhkth2t2kjek4 [2] https://issues.apache.org/**jira/browse/SOLR-3204https://issues.apache.org/jira/browse/SOLR-3204 -- http://people.apache.org/~**britter/http://people.apache.org/~britter/ http://www.systemoutprintln.**de/ http://www.systemoutprintln.de/ http://twitter.com/**BenediktRitter http://twitter.com/BenediktRitter http://github.com/britter --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-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 - 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] Finishing v1.0
I grabbed the latest build: http://people.apache.org/builds/commons/nightly/commons-csv/ -Adrian On 3/20/2013 8:43 AM, Benedikt Ritter wrote: Adrian, you've lost me. What CSVStrategy are you talking about? Are you looking at https://svn.apache.org/repos/asf/commons/proper/csv/trunk ? 2013/3/20 Adrian Crum adrian.c...@sandglass-software.com There is a part of the API that I don't like - the CSVStrategy class is mutable. I can't imagine a file's strategy changing mid-file, so from my perspective the class should be immutable. Plus, the previous version used a builder pattern that I liked. -Adrian On 3/19/2013 6:43 PM, sebb wrote: On 19 March 2013 18:38, Benedikt Ritter brit...@apache.org wrote: How do you feel about postponing some of the improvement tickets until after the initial release? Is this possible with commons release policy or do we have to resolve all open issues? As far as I'm concerned, Improvement tickets can be postponed. IMO the only items that must be fixed are regressions (not possible for first release of course). Also if there is new code with a bad API, that needs to be fixed before first release as it may be impossible to fix later without causing lots of trouble, Benedikt 2013/3/19 Adrian Crum adrian.crum@sandglass-**software.comadrian.c...@sandglass-software.com I would be interested in helping too. -Adrian On 3/19/2013 12:53 PM, Gary Gregory wrote: I am interested in seeing it through a 1.0. Let's make sure we like the API... Gary On Tue, Mar 19, 2013 at 8:39 AM, Benedikt Ritter brit...@apache.org wrote: Hi all, we have this request [1] from the Any23 community regarding [csv]. I believe we can help them in several ways. The first thing to do would be to request a git mirror of [csv] from infra, so that Any23 can use the latest trunk by cloning that mirror. The second is to finish work on [csv] and push out a 1.0 soon. When we were working on [csv] last year there were a few unresolved issues, like improving performance and general refactoring. Also we have 6 unresolved bugs. I'd like you to get involved in reviewing the state of the API. Is the API in a state that can be shipped? Does the API allow us to increase performances without breaking BC after releasing 1.0. My goal would be to fix the 6 open bugs and post pone improvements for 1.1. People are waiting for this release (remember this issue with solr [2]? They also want this library to be released!) Who has some spare time to help me with this? Regards, Benedikt [1] http://markmail.org/message/ylwdhkth2t2kjek4http://markmail.org/message/**ylwdhkth2t2kjek4 http://**markmail.org/message/**ylwdhkth2t2kjek4http://markmail.org/message/ylwdhkth2t2kjek4 [2] https://issues.apache.org/jira/browse/SOLR-3204https://issues.apache.org/**jira/browse/SOLR-3204 https://**issues.apache.org/jira/browse/**SOLR-3204https://issues.apache.org/jira/browse/SOLR-3204 -- http://people.apache.org/~britter/http://people.apache.org/~**britter/ http://people.apache.**org/~britter/http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://www.systemoutprintln.** de/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitterhttp://twitter.com/**BenediktRitter http://twitter.com/**BenediktRitterhttp://twitter.com/BenediktRitter http://github.com/britter --** --**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apac**he.orghttp://apache.org dev-unsubscribe@**commons.apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://people.apache.org/~**britter/http://people.apache.org/~britter/ http://www.systemoutprintln.**de/ http://www.systemoutprintln.de/ http://twitter.com/**BenediktRitter http://twitter.com/BenediktRitter http://github.com/britter --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-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] Finishing v1.0
Okay, that looks better. -Adrian On 3/20/2013 8:52 AM, Benedikt Ritter wrote: That build is dated 30-Jul-2007. Please have a look at trunk in SVN ;-) Benedikt 2013/3/20 Adrian Crum adrian.c...@sandglass-software.com I grabbed the latest build: http://people.apache.org/** builds/commons/nightly/**commons-csv/http://people.apache.org/builds/commons/nightly/commons-csv/ -Adrian On 3/20/2013 8:43 AM, Benedikt Ritter wrote: Adrian, you've lost me. What CSVStrategy are you talking about? Are you looking at https://svn.apache.org/repos/**asf/commons/proper/csv/trunkhttps://svn.apache.org/repos/asf/commons/proper/csv/trunk? 2013/3/20 Adrian Crum adrian.crum@sandglass-**software.comadrian.c...@sandglass-software.com There is a part of the API that I don't like - the CSVStrategy class is mutable. I can't imagine a file's strategy changing mid-file, so from my perspective the class should be immutable. Plus, the previous version used a builder pattern that I liked. -Adrian On 3/19/2013 6:43 PM, sebb wrote: On 19 March 2013 18:38, Benedikt Ritter brit...@apache.org wrote: How do you feel about postponing some of the improvement tickets until after the initial release? Is this possible with commons release policy or do we have to resolve all open issues? As far as I'm concerned, Improvement tickets can be postponed. IMO the only items that must be fixed are regressions (not possible for first release of course). Also if there is new code with a bad API, that needs to be fixed before first release as it may be impossible to fix later without causing lots of trouble, Benedikt 2013/3/19 Adrian Crum adrian.crum@sandglass-**softw**are.comhttp://software.com adrian.crum@sandglass-**software.comadrian.c...@sandglass-software.com I would be interested in helping too. -Adrian On 3/19/2013 12:53 PM, Gary Gregory wrote: I am interested in seeing it through a 1.0. Let's make sure we like the API... Gary On Tue, Mar 19, 2013 at 8:39 AM, Benedikt Ritter brit...@apache.org wrote: Hi all, we have this request [1] from the Any23 community regarding [csv]. I believe we can help them in several ways. The first thing to do would be to request a git mirror of [csv] from infra, so that Any23 can use the latest trunk by cloning that mirror. The second is to finish work on [csv] and push out a 1.0 soon. When we were working on [csv] last year there were a few unresolved issues, like improving performance and general refactoring. Also we have 6 unresolved bugs. I'd like you to get involved in reviewing the state of the API. Is the API in a state that can be shipped? Does the API allow us to increase performances without breaking BC after releasing 1.0. My goal would be to fix the 6 open bugs and post pone improvements for 1.1. People are waiting for this release (remember this issue with solr [2]? They also want this library to be released!) Who has some spare time to help me with this? Regards, Benedikt [1] http://markmail.org/message/**ylwdhkth2t2kjek4http://markmail.org/message/ylwdhkth2t2kjek4 http://**markmail.org/message/ylwdhkth2t2kjek4http://markmail.org/message/**ylwdhkth2t2kjek4 http://**markmail.org/**message/**ylwdhkth2t2kjek4http://markmail.org/message/**ylwdhkth2t2kjek4 htt**p://markmail.org/message/**ylwdhkth2t2kjek4http://markmail.org/message/ylwdhkth2t2kjek4 [2] https://issues.apache.org/**jira/browse/SOLR-3204https://issues.apache.org/jira/browse/SOLR-3204 https://**issues.apache.org/**jira/**browse/SOLR-3204https://issues.apache.org/**jira/browse/SOLR-3204 https://**issues.apache.org/**jira/browse/**SOLR-3204http://issues.apache.org/jira/browse/**SOLR-3204 https:**//issues.apache.org/jira/**browse/SOLR-3204https://issues.apache.org/jira/browse/SOLR-3204 -- http://people.apache.org/~**britter/http://people.apache.org/~britter/ http://people.apache.**org/~**britter/http://people.apache.org/~**britter/ http://people.apache.**org/~**britter/http://people.apache.** org/~britter/ http://people.apache.org/~britter/ http://www.systemoutprintln.**de/ http://www.systemoutprintln. de/ http://www.systemoutprintln.**de/http://www.systemoutprintln.de/ http://twitter.com/**BenediktRitterhttp://twitter.com/BenediktRitter http://twitter.**com/**BenediktRitterhttp://twitter.com/**BenediktRitter http://twitter.com/BenediktRitterhttp://twitter.com/**BenediktRitter http://twitter.**com/BenediktRitterhttp://twitter.com/BenediktRitter http://github.com/britter --**--** --** --**- To unsubscribe, e-mail: dev-unsubscribe@commons.apac**he.org http://apache.org** dev-unsubscribe@**commons.**apache.org http://commons.apache.org dev-unsubscribe@**commons.apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://people.apache.org/~britter/http://people.apache.org/~**britter/ http
Re: [BeanUtils2] WeakHashMap is not a cache (?)
Apache OFBiz has a soft reference cache implementation. -Adrian On 8/13/2012 1:07 PM, Simone Tripodi wrote: guten morgen Bene, I have not a strong opinion about it, I am convinced anyway that the original BU authors (BU2 at the beginning was a tentative to refurbish BU) adopted the WeakHashMap NOT with the purpose of implementing a `cache` in the strict sense we are used to. We should go back to the ML history and find related discussions about it to understand that decision. If we need to switch implementation, in Apache Cocoon we developed a simple LRU cache hacking the LinkedHashMap, we could import and adapt that version - it would be better keeping BU2 dependencies-less. Thanks, -Simo [1] http://s.apache.org/9zN http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Aug 13, 2012 at 1:11 PM, Benedikt Ritter benerit...@gmail.com wrote: Hi, I just came across this post: http://www.codeinstructions.com/2008/09/weakhashmap-is-not-cache-understanding.html Now i'm wondering what you think about it, since we are using the WeakHashMap for BU2. Maybe we should be looking for an alternative caching mechanism? Any suggestions? Best regards, Benedikt - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [BeanUtils2] WeakHashMap is not a cache (?)
http://ci.apache.org/projects/ofbiz/site/javadocs/org/ofbiz/base/util/cache/package-summary.html -Adrian On 8/13/2012 2:51 PM, Simone Tripodi wrote: Hi Adrian, any direct link? TIA! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Aug 13, 2012 at 3:19 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: Apache OFBiz has a soft reference cache implementation. -Adrian On 8/13/2012 1:07 PM, Simone Tripodi wrote: guten morgen Bene, I have not a strong opinion about it, I am convinced anyway that the original BU authors (BU2 at the beginning was a tentative to refurbish BU) adopted the WeakHashMap NOT with the purpose of implementing a `cache` in the strict sense we are used to. We should go back to the ML history and find related discussions about it to understand that decision. If we need to switch implementation, in Apache Cocoon we developed a simple LRU cache hacking the LinkedHashMap, we could import and adapt that version - it would be better keeping BU2 dependencies-less. Thanks, -Simo [1] http://s.apache.org/9zN http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Aug 13, 2012 at 1:11 PM, Benedikt Ritter benerit...@gmail.com wrote: Hi, I just came across this post: http://www.codeinstructions.com/2008/09/weakhashmap-is-not-cache-understanding.html Now i'm wondering what you think about it, since we are using the WeakHashMap for BU2. Maybe we should be looking for an alternative caching mechanism? Any suggestions? Best regards, Benedikt - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Is this disguised fishing?
I haven't received that specific email, but I always reply back that any discussions about Apache projects should be kept on the mailing lists. -Adrian On 7/12/2012 1:48 PM, Sébastien Brisard wrote: Dear all, please find below a message I've received. It was sent to my apache address, which I barely use (but can easily be retrieved from my apache login). I'm just wondering whether this message might be a (very clever !) attempt at fishing. I don't think so, it does not have the usual flavour. Is it safe to answer? Has anyone else received such a message? Is there someone at Apache in charge of security which should be informed of this message? Thanks for your answers, Sébastien -- Forwarded message -- From: Yida Tao yida1...@gmail.com Date: 2012/7/12 Subject: Help developers understand program changes -- Seeking your feedback To: celes...@apache.org Dear Sébastien, This is Yida Tao, a PhD student of Computer Science and Engineering in Hong Kong University of Science and Technology. I’m currently working on a research project using Apache Commons Math as an evaluation subject. Our observation is that program changes (or commits) sometimes mix several issues together. For example, a single commit may actually fix three different bugs, or it may perform some refactorings, fix a minor bug and then implement a new feature. Such commit (we refer to it as the “composite change”) might reduce the change’s understandability and make the code review much harder. Therefore, our research goal is to automatically decompose a composite change into “slices”; each slice is aligned with one particular issue addressed. For example, if a change fixes three different bugs, we would like to see this change to be decomposed into three “slices”, each corresponds to one bug-fix. We would like to invite you to a short survey (around 5 - 10 minutes) on our research result. In particular, below is an example of applying our technique on one of your commits (revision 1210359 for Apache Commons Math). Our technique automatically decomposes your commit into 3 slices. You can view all the slices of the commit at http://webproject1.cse.ust.hk/ChangeSlicing/Survey/Math1210359.aspx We really appreciate it if you could let us know your opinions on the following two questions by replying this email: 1 Do you think the above example of slices is accurate? (Please assign a value from 0 to 4: 0 - Not accurate at all, 1 - Not accurate, 2 - Not sure, 3 - Accurate, 4 - Very accurate) 2 Do you think in general sliced changes (by our automatic change slicing technique) would be useful for other developers to review and understand your changes? (Please assign a value from 0 to 4: 0 - Not useful at all, 1 - Not useful, 2 - Not sure, 3 - Useful, 4 - Very useful) Thank you for your time! Your feedback is very valuable to us! Best Regards, Yida Tao PhD student Department of Computer Science and Engineering The Hong Kong University of Science and Technology Email: ida...@cse.ust.hk - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons JMS Project
I would like to be involved with this once it has found a home. -Adrian On 7/9/2012 9:12 PM, Scott England-Sullivan wrote: Hello, I have developed a new component for the Apache Camel project written using pure Java JMS APIs (the current component is a Spring JMS wrapper). There have been requests made to make the API pulled out of the Camel component and to place them in a commons project for use by other projects (CXF) that are looking to move away from the Spring JMS API. As such I am looking for guidance on where to start. The guides reference contributing to current standing projects but not on how to create a submission for a new commons project, namely, commons-jms. Any help or pointers would be appreciated. Thanks in advance, Scott ES - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collections] Cleanup of trunk
On 6/24/2012 12:25 PM, sebb wrote:
On 24 June 2012 10:28, Thomas Neidhart thomas.neidh...@gmail.com wrote:
Hi,
I recently started to work more on collections and cleaning up the trunk
to make it a candidate for a release and would like to ask a few questions:
- there is still lots of javadoc missing, moving the source code level
to Java 1.6 would allow the use of @Override in more places (instead
of putting a /** {inheritDoc} */ everywhere)
AFAICT Javadoc is automatically inherited for methods that implement
an interface.
Being able to add @Override to an interface implementation does not
gain anything.
True, you don't gain anything in JavaDocs, but it is still worth adding
because the compiler will let you know if your implementation does not
match the interface.
-Adrian
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1348334 - in /commons/proper/proxy/branches/version-2.0-work/stub/src/main/java/org/apache/commons/proxy2/stub: AnnotationFactory.java StubConfigurer.java
Actually, that cast should not be necessary. Try
return AnnotationFactory.AnnotationgetStubType();
-Adrian
On 6/9/2012 12:05 PM, sebb wrote:
On 9 June 2012 08:54,mben...@apache.org wrote:
Author: mbenson
Date: Sat Jun 9 07:54:02 2012
New Revision: 1348334
URL: http://svn.apache.org/viewvc?rev=1348334view=rev
Log:
generics precision
Modified:
commons/proper/proxy/branches/version-2.0-work/stub/src/main/java/org/apache/commons/proxy2/stub/AnnotationFactory.java
commons/proper/proxy/branches/version-2.0-work/stub/src/main/java/org/apache/commons/proxy2/stub/StubConfigurer.java
Modified:
commons/proper/proxy/branches/version-2.0-work/stub/src/main/java/org/apache/commons/proxy2/stub/AnnotationFactory.java
URL:
http://svn.apache.org/viewvc/commons/proper/proxy/branches/version-2.0-work/stub/src/main/java/org/apache/commons/proxy2/stub/AnnotationFactory.java?rev=1348334r1=1348333r2=1348334view=diff
==
---
commons/proper/proxy/branches/version-2.0-work/stub/src/main/java/org/apache/commons/proxy2/stub/AnnotationFactory.java
(original)
+++
commons/proper/proxy/branches/version-2.0-work/stub/src/main/java/org/apache/commons/proxy2/stub/AnnotationFactory.java
Sat Jun 9 07:54:02 2012
@@ -214,8 +214,9 @@ public class AnnotationFactory {
* {@inheritDoc}
*/
@Override
-public Class? extends Annotation getStubType() {
-return AnnotationFactory.getStubType();
+@SuppressWarnings(unchecked)
Why is it safe to ignore the warning?
This should be documented in a comment please.
+public ClassAnnotation getStubType() {
+return (ClassAnnotation) AnnotationFactory.getStubType();
}
/**
Modified:
commons/proper/proxy/branches/version-2.0-work/stub/src/main/java/org/apache/commons/proxy2/stub/StubConfigurer.java
URL:
http://svn.apache.org/viewvc/commons/proper/proxy/branches/version-2.0-work/stub/src/main/java/org/apache/commons/proxy2/stub/StubConfigurer.java?rev=1348334r1=1348333r2=1348334view=diff
==
---
commons/proper/proxy/branches/version-2.0-work/stub/src/main/java/org/apache/commons/proxy2/stub/StubConfigurer.java
(original)
+++
commons/proper/proxy/branches/version-2.0-work/stub/src/main/java/org/apache/commons/proxy2/stub/StubConfigurer.java
Sat Jun 9 07:54:02 2012
@@ -79,7 +79,7 @@ public abstract class StubConfigurerT
* Get the stubType.
* @return ClassT
*/
-public Class? extends T getStubType() {
+public ClassT getStubType() {
return stubType;
}
-
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: Git support?
+1 on trying it out on a single component. -Adrian On 5/19/2012 9:08 AM, Luc Maisonobe wrote: Le 16/05/2012 15:41, Jochen Wiedmann a écrit : Well, with our multitude of projects, it might make sense to ask for one or two of them being migrated, so that we gather the experience. (I've got none so far.) Would anyone volunteer for the job of being involved? I was wondering if we should switch all components at the same time when everything is ready or as you propose switch one or two components early and use them as a template for other components. I am really interested in using Git access, as I already uses it for non-Apache projects and am really happy with it. In fact, for Apache projects I use git-svn. If we propose to switch one component first, I would be happy to volunteer for switching [math]. What do other developers think about Jochen idea ? Luc Thanks, Jochen On Wed, May 16, 2012 at 9:52 AM, Christian Grobmeier grobme...@gmail.com wrote: Its still in development. I have asked to switch to git with log4php before a few weeks and the answer was it is possible, if one of us gets involved in the git@apache project. I assume it is the the here. Its definitely not GA at the moment. On Wed, May 16, 2012 at 9:39 AM, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: Completely OT: Is Git supported now? https://issues.apache.org/jira/browse/INFRA-4703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13276416#comment-13276416 -- Bildung kommt von Bildschirm und nicht von Buch, sonst hieße es ja Buchung. Dieter Hildebrandt - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Is that 1 or l or I ?
Personally, I despise single character parameters/variable names. Seriously, is it that much work to type a few extra characters and make the name meaningful? -Adrian On 3/14/2012 1:33 PM, sebb wrote: I noticed that some of the CSV methods uses int l (ell). This is unfortunately very similar to 1 (one) in many fonts. ExtendedBufferedReader.read(...) and UnicodeUnescapeReader.read(...) both do this. Now that would perhaps be a good candidate for a CheckStyle report ?! P.S. the subject has 1 (one) then l (ell) then I (upper-case i) in case you cannot tell. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Is that 1 or l or I ?
Except in nested loops: Which integer is being incremented, the inner loop or outer loop? If the outer loop used outer instead of i, and the inner loop used inner instead of j, then the loop being incremented is obvious. Idioms make sense as long as they're *your* idioms. To others it's confusing. -Adrian On 3/14/2012 5:11 PM, sebb wrote: On 14 March 2012 16:39, Adrian Crumadrian.c...@sandglass-software.com wrote: Personally, I despise single character parameters/variable names. Seriously, is it that much work to type a few extra characters and make the name meaningful? Sometimes single char names are clearer. E.g. in for loops, using i and j is such a common idiom that renaming won't necessarily improve readability. -Adrian On 3/14/2012 1:33 PM, sebb wrote: I noticed that some of the CSV methods uses int l (ell). This is unfortunately very similar to 1 (one) in many fonts. ExtendedBufferedReader.read(...) and UnicodeUnescapeReader.read(...) both do this. Now that would perhaps be a good candidate for a CheckStyle report ?! P.S. the subject has 1 (one) then l (ell) then I (upper-case i) in case you cannot tell. - 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Conversion utility class
Commons Convert is Java only, so there is no need to support mixed languages. The current trunk supports Maven and Ant build tools, and there are support files for Eclipse. -Adrian On 2/5/2012 3:42 PM, ma...@nimp.co.uk wrote: This seems to fit well with the functionality of my utility class. Please let me know what do you think about the documentation issue. Anyone has an idea to generate javadoc from a scala code ? Also, what do you use to build the library ? does it handle mixed language projects ? I am using JIdea and I heard it can handle such project but I don't know if netbeans or eclipse can... Sebastien Original Message: - From: Adrian Crum adrian.c...@sandglass-software.com Date: Sat, 04 Feb 2012 16:53:25 + To: dev@commons.apache.org Subject: Re: Conversion utility class Have you seen Commons Convert? http://commons.apache.org/sandbox/convert/ -Adrian On 2/4/2012 5:38 AM, ma...@nimp.co.uk wrote: Hello, I am developing a utility class and would like to contribute it to an Apache project. I am writing to know if Apache commons is the right project, which sub project would be the right place and then how to do. Background: I Work on a regular basis with embedded devices, driving them and analyzing the results using Java and Scala code. In this domain, it is often required to manipulate data at bit level, and the bit ordering and byte ordering tends to vary from one type of device to another. I did not found an open source library for converting basic data types between each other, changing endianness and bit ordering, so I am writing one. As it is rather boring and time consuming to do so, I would like to share it with others. The other motivation being that other people may find bugs and performance improvement... Where to contribute ? Apache Commons Lang seems to be the right place for that kind of utility class, however, my utility class is coded in Scala, is that ok ? I use it in java programs without any problems since scala basic types are actually java basic types, same for arrays. From user point of view, this is transparent, however the documentation is not javadoc but scaladoc, that's similar but user will definitely notice and may be confused. It seems there is no tool to generate a javadoc from a scala file :-S Details: If you want to have a look, the source, test and doc are here: http://www.nimp.co.uk/free/conv/ Best regards, Sebastien mail2web.com – Enhanced email for the mobile individual based on Microsoft® Exchange - http://link.mail2web.com/Personal/EnhancedEmail - 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 mail2web LIVE – Free email based on Microsoft® Exchange technology - http://link.mail2web.com/LIVE - 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: Conversion utility class
Have you seen Commons Convert? http://commons.apache.org/sandbox/convert/ -Adrian On 2/4/2012 5:38 AM, ma...@nimp.co.uk wrote: Hello, I am developing a utility class and would like to contribute it to an Apache project. I am writing to know if Apache commons is the right project, which sub project would be the right place and then how to do. Background: I Work on a regular basis with embedded devices, driving them and analyzing the results using Java and Scala code. In this domain, it is often required to manipulate data at bit level, and the bit ordering and byte ordering tends to vary from one type of device to another. I did not found an open source library for converting basic data types between each other, changing endianness and bit ordering, so I am writing one. As it is rather boring and time consuming to do so, I would like to share it with others. The other motivation being that other people may find bugs and performance improvement... Where to contribute ? Apache Commons Lang seems to be the right place for that kind of utility class, however, my utility class is coded in Scala, is that ok ? I use it in java programs without any problems since scala basic types are actually java basic types, same for arrays. From user point of view, this is transparent, however the documentation is not javadoc but scaladoc, that's similar but user will definitely notice and may be confused. It seems there is no tool to generate a javadoc from a scala file :-S Details: If you want to have a look, the source, test and doc are here: http://www.nimp.co.uk/free/conv/ Best regards, Sebastien mail2web.com – Enhanced email for the mobile individual based on Microsoft® Exchange - http://link.mail2web.com/Personal/EnhancedEmail - 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] What about Duration class? (org.apache.commons.lang.time)
On 1/26/2012 6:59 AM, Henri Yandell wrote: On Wed, Jan 25, 2012 at 2:14 PM, Christian Grobmeier grobme...@gmail.com wrote: On Wed, Jan 25, 2012 at 9:17 PM, Benedikt Ritter b...@systemoutprintln.de wrote: But i found only discussions about durationjoda-time dated 2004. (http://markmail.org/thread/733yqv5zwzsngj3j) Now i really need in Duration functionality (especially such as Duration.parse(String)). I heard about joda-time a while ago. My impression is, that the joda project is not that active anymore (please correct me, if I'm wrong). So I would vouch for additions to lang regarding durations. What I'm also really missing in lang.time is conversation of durations. For example: DurationUtils.convertToMinutes(long seconds). Joda Time is imho a great lib. Before a few weeks I replaced all the JDK stuff with Joda and it really saved my life. There was a release in July 2011 or so and my impression is more this lib is stable and does not need many releases. Actually I can't imagine a feature I miss in Joda at the moment. I don't understand the Commons point on this issue. - Commons Lang doesn't need in own implementation of this functionality and you suggest use joda-time? - Commons Lang needs in simplelightweight implementation of Duration? Also i cannot find correspond issue in jira (but Eric Crampton in 2004 wrote about Commons Lang task list that there is a need for DateRange/Duration classes). As you said, it is a while ago, since this was discussed. So let's review this topic again. What are your thoughts? Hen (who is mainly behind lang) and Gary already mentioned, they don't want to replicate Joda code into [lang]. I don't see any reasons why we should do that now. Instead I would prefer to mark the time package as deprecated and point users to joda. time does rely on jdk classes and as I have found out by own experience, it is dangerous to work with them. Long-term vision wise; my expectation is to drop our time package like a lead balloon as soon as Joda enters the JDK :) Just to clarify: Joda is not entering the JDK. JSR-310 has been proposed and might make it into the JDK, but JSR-310 is not Joda. http://jcp.org/en/jsr/detail?id=310 -Adrian - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
