Re: [math] javadoc unbalanced code
Thanks for the patch Dennis! Feel free create a JIRA ticket [1] for
this issue, where you can attach your patch (and maybe more ;). One
little suggestion for improvement: According to [2] {@code } should be
used in instead of code and tt.
Regards,
Benedikt
[1] https://issues.apache.org/jira
[2] https://blogs.oracle.com/darcy/entry/javadoc_tip_code_and_literal
Am 9. März 2012 11:34 schrieb Dennis Hendriks d.hendr...@tue.nl:
Hi all,
See http://commons.apache.org/math/apidocs/index-all.html and scroll to the
section 'D'. Observe how in method discardMostRecentElements(int) in class
org.apache.commons.math3.util.ResizableDoubleArray, the style changes to
larger font. This can be fixed using this patch:
Index: src/main/java/org/apache/commons/math3/util/ResizableDoubleArray.java
===
--- src/main/java/org/apache/commons/math3/util/ResizableDoubleArray.java
(revision 1298781)
+++ src/main/java/org/apache/commons/math3/util/ResizableDoubleArray.java
(working copy)
@@ -457,7 +457,7 @@
}
/**
- * Discards the codeicode last elements of the array. For example,
+ * Discards the codei/code last elements of the array. For
example,
* if the array contains the elements 1,2,3,4, invoking
* codediscardMostRecentElements(2)/code will cause the last two
elements
* to be discarded, leaving 1,2 in the array. Throws
illegalArgumentException
and is obviously due to codei/code not being balanced. Similar issues
exist elsewhere in the javadoc, for instance at the isSame(Chromosome)
method in the org.apache.commons.math3.genetics.BinaryChromosome class.
Best regards,
Dennis
-
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] Performance comparison
Am 11. März 2012 15:05 schrieb Emmanuel Bourg ebo...@apache.org: Hi, I compared the performance of Commons CSV with the other CSV parsers available. I took the world cities file from Maxmind as a test file [1], it's a big file of 130M with 2.8 million records. Here are the results obtained on a Core 2 Duo E8400 after several iterations to let the JIT compiler kick in: Direct read 750 ms Java CSV 3328 ms Super CSV 3562 ms (+7%) OpenCSV 3609 ms (+8.4%) GenJava CSV 3844 ms (+15.5%) Commons CSV 4656 ms (+39.9%) Skife CSV 4813 ms (+44.6%) I also tried Nuiton CSV and Esperio CSV but I couldn't figure how to use them. I haven't analyzed why Commons CSV is slower yet, but it seems there is room for improvements. The memory usage will have to be compared too, I'm looking for a way to measure it. Hey Emmanuel, I have some spare time to help you with this. I'll check out the latest source tonight. Any suggestion where to start? Regards, Benedikt Emmanuel Bourg [1] http://www.maxmind.com/download/worldcities/worldcitiespop.txt.gz - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [csv] Performance comparison
Am 11. März 2012 21:21 schrieb Emmanuel Bourg ebo...@apache.org: Le 11/03/2012 16:53, Benedikt Ritter a écrit : I have some spare time to help you with this. I'll check out the latest source tonight. Any suggestion where to start? Hi Benedikt, thank you for helping. You can start looking at the source of CSVParser if anything catch your eyes, and then run a profiler to try and identify the performance critical parts that could be improved. Hi Emmanuel, I've started to dig my way through the source. I've not done too much performance measuring in my career yet. I would use VisualVM for profiling, if you don't know anything better. And how about some performance junit tests? They may not be as accurate as a profiler, but they can give you a feeling, whether you are on the right way. Benedikt Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[csv] Serializable on CSVFormat
Hi, I just saw that CSVFormat implements Serializable, but neither does it provide a no-arg constructor nor any of the special serialization methods (and it has no custom serialUID). Is this the way it is supposed to be? Benedikt - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jira] [Created] (CSV-55) Replace while(true)-loop in CSVParser.getRecord() with do-while-loop
Hey Gary,
thanks for the hint. Should I just send patches for minor changes like
that to the ML (plain text, not as attachment of course ;)?
Benedikt
Am 12. März 2012 15:03 schrieb Gary Gregory ggreg...@rocketsoftware.com:
I do not think we need to tickets for this kind of change.
Gary
On Mar 12, 2012, at 9:59, Benedikt Ritter (Created) (JIRA)
j...@apache.org wrote:
Replace while(true)-loop in CSVParser.getRecord() with do-while-loop
Key: CSV-55
URL: https://issues.apache.org/jira/browse/CSV-55
Project: Commons CSV
Issue Type: Improvement
Components: Parser
Affects Versions: 1.0
Reporter: Benedikt Ritter
Priority: Trivial
The current implementation of {{getRecords()}} uses a while(true) loop, that
gets canceled by an if statement:
{code:java}
while (true) {
reusableToken.reset();
lexer.nextToken(reusableToken);
// omitted
if(reusableToken.type != TOKEN) {
break;
}
}
{code}
This should be replaced by a do-while-loop:
{code:java}
do {
reusableToken.reset();
lexer.nextToken(reusableToken);
// omitted
} while (reusableToken.type == TOKEN);
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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: [jira] [Created] (CSV-55) Replace while(true)-loop in CSVParser.getRecord() with do-while-loop
Am 12. März 2012 15:39 schrieb Gary Gregory garydgreg...@gmail.com:
On Mon, Mar 12, 2012 at 10:17 AM, Benedikt Ritter benerit...@googlemail.com
wrote:
Hey Gary,
thanks for the hint. Should I just send patches for minor changes like
that to the ML (plain text, not as attachment of course ;)?
Hm, I thought a comitter was submitting these... JIRA is the way to submit
code indeed.
Feel free to vouch for me ;)
But note that the best way is to attach a diff file base on the SVN trunk.
Yes, I was about to create a patch, but then I realized, that the code
formatting is not correct. Can you tell me where I can get the right
formatter configuration file for cvs (I'm using eclipse)? The source
does not look like the default maven style...
TIA,
Benedikt
Gary
Benedikt
Am 12. März 2012 15:03 schrieb Gary Gregory ggreg...@rocketsoftware.com:
I do not think we need to tickets for this kind of change.
Gary
On Mar 12, 2012, at 9:59, Benedikt Ritter (Created) (JIRA)
j...@apache.org wrote:
Replace while(true)-loop in CSVParser.getRecord() with do-while-loop
Key: CSV-55
URL: https://issues.apache.org/jira/browse/CSV-55
Project: Commons CSV
Issue Type: Improvement
Components: Parser
Affects Versions: 1.0
Reporter: Benedikt Ritter
Priority: Trivial
The current implementation of {{getRecords()}} uses a while(true) loop,
that gets canceled by an if statement:
{code:java}
while (true) {
reusableToken.reset();
lexer.nextToken(reusableToken);
// omitted
if(reusableToken.type != TOKEN) {
break;
}
}
{code}
This should be replaced by a do-while-loop:
{code:java}
do {
reusableToken.reset();
lexer.nextToken(reusableToken);
// omitted
} while (reusableToken.type == TOKEN);
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0
Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK
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] Performance comparison
Am 12. März 2012 11:31 schrieb Emmanuel Bourg ebo...@apache.org: I have identified the performance killer, it's the ExtendedBufferedReader. It implements a complex logic to fetch one character ahead, but this extra character is rarely used. I have implemented a simpler look ahead using mark/reset as suggested by Bob Smith in CSV-42 and the performance improved by 30%. Now the parsing is down to 3406 ms, and that's almost without touching the parser yet. great work Emmanuel! looking at my profiler, I can say that 70% of the time is spend in ExtendedBufferedReader.read(). This is no wonder, since read() is the method that does the actual work. However, we should try to minimize accesses to read(). For example isEndOfLine() calls read() two times. And isEndOfLine() get's called 5 times by CSVLexer.nextToken() and it's submethods. The hole logic behind CSVLexer.nextToken() is very hard to read (IMHO). Maybe a some refactoring would help to make it easier to identify bottle necks? Benedikt Emmanuel Bourg Le 11/03/2012 15:05, Emmanuel Bourg a écrit : Hi, I compared the performance of Commons CSV with the other CSV parsers available. I took the world cities file from Maxmind as a test file [1], it's a big file of 130M with 2.8 million records. Here are the results obtained on a Core 2 Duo E8400 after several iterations to let the JIT compiler kick in: Direct read 750 ms Java CSV 3328 ms Super CSV 3562 ms (+7%) OpenCSV 3609 ms (+8.4%) GenJava CSV 3844 ms (+15.5%) Commons CSV 4656 ms (+39.9%) Skife CSV 4813 ms (+44.6%) I also tried Nuiton CSV and Esperio CSV but I couldn't figure how to use them. I haven't analyzed why Commons CSV is slower yet, but it seems there is room for improvements. The memory usage will have to be compared too, I'm looking for a way to measure it. Emmanuel Bourg [1] http://www.maxmind.com/download/worldcities/worldcitiespop.txt.gz - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [csv] Performance comparison
Am 12. März 2012 17:22 schrieb Emmanuel Bourg ebo...@apache.org: Le 12/03/2012 17:03, Benedikt Ritter a écrit : The hole logic behind CSVLexer.nextToken() is very hard to read (IMHO). Maybe a some refactoring would help to make it easier to identify bottle necks? Yes I started investigating in this direction. I filed a few bugs regarding the behavior of the escaping that aim at clarifying the parser. I think the nextToken() method should be broken into smaller methods to help the JIT compiler. I would start by eliminating the Token parameter. You could either create a new token on each method call and return that one instead of reusing on the gets passed in or you could use a private field currentToken in CSVLexer. But I think that object creation costs for a data object like Token can be considered irrelevant (so creating one in each method call will not hurt us). The JIT does some surprising things, I found that even unused code branches can have an impact on the performance. For example if simpleTokenLexer() is changed to not support escaped characters, the performance improves by 10% (the input has no escaped character). And that's not merely because an if statement was removed. If I add a System.out.println() in this if block that is never called, the performance improves as well. So any change to the parser will have to be carefully tested. Innocent changes can have a significant impact. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[cvs] CSVLexer.isEndOfLine(int c) makes assumptions on the line separator of a CSVFormat
Hi,
while looking for potential performance optimization I came across
CSVLexer.isEndOfLine(int c). Here is the source:
private boolean isEndOfLine(int c) throws IOException {
// check if we have \r\n...
if (c == '\r' in.lookAhead() == '\n') {
// note: does not change c outside of this method !!
c = in.read();
}
return (c == '\n' || c == '\r');
}
this method assumes, that a line separator will always be \r or
\r\n. This is true for the pre-configured CSVFormats EXCEL, TDF and
MYSQL. I'm not a pro when it comes to file encoding, but isn't there
the possibility that new encodings will have different line
separators?
If that is the case, isEndOfLine() should somehow use
format.getLineSeparator().
For example the lookAhead only has to be made, if
lineSeperator.length() 1. This may have a positive impact on the
performance of parsing files with an encoding whose line separator is
only one char long.
Benedikt
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [cvs] CSVLexer.isEndOfLine(int c) makes assumptions on the line separator of a CSVFormat
Am 12. März 2012 18:24 schrieb Emmanuel Bourg ebo...@apache.org: Le 12/03/2012 18:17, Benedikt Ritter a écrit : this method assumes, that a line separator will always be \r or \r\n. This is true for the pre-configured CSVFormats EXCEL, TDF and MYSQL. I'm not a pro when it comes to file encoding, but isn't there the possibility that new encodings will have different line separators? Indeed, there are unicode line separators, see: https://issues.apache.org/jira/browse/CSV-51 If that is the case, isEndOfLine() should somehow use format.getLineSeparator(). For example the lookAhead only has to be made, if lineSeperator.length() 1. This may have a positive impact on the performance of parsing files with an encoding whose line separator is only one char long. CSVFormat defines a line separator, but it's only used by CSVPrinter. I'm not sure if we should restrict to this separator when parsing. I'm not sure if I got you right. You have to pass a CSVFormat if you want to construct a CSVLexer(), so we could use the lexer's internal CSVformat. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [cvs] CSVLexer.isEndOfLine(int c) makes assumptions on the line separator of a CSVFormat
Am 12. März 2012 18:38 schrieb Emmanuel Bourg ebo...@apache.org:
Le 12/03/2012 18:31, Benedikt Ritter a écrit :
I'm not sure if I got you right. You have to pass a CSVFormat if you
want to construct a CSVLexer(), so we could use the lexer's internal
CSVformat.
Yes that's what I understood, when I mention the parser it includes the
lexer as well.
you wrote about the printer ;) now I know what you mean.
I think the parser should look for any line separator and not only the one
defined in the format. Otherwise the user will have to know in advance the
line separator of the input files, and that's not always possible.
Okay, then I guess the best would be to have some place where all
possible line separators are defined. That could be a custom enum,
that has a string value.
then we could do something like:
private isEndOfLine(int c){
for(LineSeparator separator : LineSeparator.values()) {
// do what is necessary to decide if we have a line separator
and return true
}
return false;
}
Since the issue is tagged 1.x, I guess it is not our priority,
although I see the potential for a performance improvements.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Longest common substring / Suffix Tree
Am 12. März 2012 21:20 schrieb Thomas Neidhart thomas.neidh...@gmail.com: Hi, on the weekend, I started to work on issue LANG-680 (https://issues.apache.org/jira/browse/LANG-680), which is about adding support for finding the longest common substring of a set of Strings. Suffix Trees are a standard data structure to efficiently solve this problem, and I created a variant of Ukkonen's algorithm to construct such a tree in linear time. After some research to create a generalized version of it (to support multiple strings), I found a very nice implementation from Alessandro Bahgat (https://github.com/abahgat/suffixtree), which is very similar to my own, and contacted the author if he is interested to put his code under apache license (which he did already). So the question basically is how to proceed, as adding a data structure like a Suffix Tree to commons-lang may be out-of-scope. On the other hand there are several string related problems that can be efficiently solved with a Suffix Tree: * longest common substring * longest repeated substring * exact string set matching * palindrom finding * finding frequent substrings Maybe it would make sense to create an new class SubstringUtils instead of adding all that logic to StringUtils (which already has a fair amount of funtionality). Implementing a longest common substring for two strings is trivial (using dynamic programming ~20 lines of code), but for a set of strings a suffix tree would be needed. Henri already outlined a possible API as comment to the issue, which I like, so what do other people think about adding a suffix tree to commons-lang? 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: [csv] Headers
I think transforming the result of the parse process into instances of some class is a different concern. That should not be part of as CSVParser. In Hibernate they use ResultTransformers for this purpose [1]. I think we should separate this concerns as well. [1] http://docs.jboss.org/hibernate/orm/3.3/api/org/hibernate/transform/ResultTransformer.html Am 13. März 2012 10:03 schrieb Emmanuel Bourg ebo...@apache.org: Le 13/03/2012 09:56, sebb a écrit : It needs to be possible to access columns by index without having to use annotations. That's still possible with the low level API. I'm just exploring the features I would expect of a bean mapping. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons Parent reports
Am 13. März 2012 14:15 schrieb Gary Gregory garydgreg...@gmail.com: On Tue, Mar 13, 2012 at 8:39 AM, Torsten Curdt tcu...@vafer.org wrote: I find checkstyle to be not very useful. It's more hassle than it's worth. It's like pointing fingers instead of helping. If you want to foster a certain code style provide eclipse and intellij formatter settings instead - that's actually helping. Especially if you run them before a release. I'd /love/ to have IDE settings for formatting saved in a project. This is the 21st century, all IDEs support this, if you do not use an IDE (hi Gilles), then, well, you probably also like driving a stick for control :) The only tricky part is how organize such a folder to account for different IDEs and versions. For example ide/eclipse/3.7.1, ide/intellij/10.5.3, and so on. Then you can move the IDE files to where each IDE wants it. Very big +1 Gary! It would make contributing to the various components so much easier (at least for people how use an IDE ;). I guess we should discuss this on a new thread. Gary The basic code style is like logging - people spent just wait too much time on this. Thinks we really should care about are in the findbugs and PMD report. I don't see why we should make checkstyle part of the projects by default. My 2 cents, Torsten On Tue, Mar 13, 2012 at 1:14 PM, Simone Tripodi simonetrip...@apache.org wrote: Hi Torsten! -1 for checkstyle With my +1 I meant that, as we discussed in another thread, the parent could provide a default - but overridable - configuration; I think that having at least one metric of code style measure in each component would be nice to have, so unless other preferences, the parent suggests a default config I would like to understand better your PoV (that would influence mine): which are your concerns about having the checkstyle? many thanks in advance, all the best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.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 JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK 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: r1300661 - /commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVParser.java
Am 14. März 2012 18:43 schrieb s...@apache.org:
Author: sebb
Date: Wed Mar 14 17:43:35 2012
New Revision: 1300661
URL: http://svn.apache.org/viewvc?rev=1300661view=rev
Log:
CSV-60 CSVParser.iterator().remove() should throw throw new
UnsupportedOperationException()
is it reasonable to add a unit test, that makes sure an
UnsupportedOperationException is thrown?
Modified:
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVParser.java
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=1300661r1=1300660r2=1300661view=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 Mar 14 17:43:35 2012
@@ -212,7 +212,9 @@ public class CSVParser implements Iterab
}
}
- public void remove() { }
+ public void remove() {
+ throw new UnsupportedOperationException();
+ }
};
}
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1300661 - /commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVParser.java
Am 14. März 2012 20:33 schrieb Benedikt Ritter benerit...@googlemail.com:
Am 14. März 2012 18:43 schrieb s...@apache.org:
Author: sebb
Date: Wed Mar 14 17:43:35 2012
New Revision: 1300661
URL: http://svn.apache.org/viewvc?rev=1300661view=rev
Log:
CSV-60 CSVParser.iterator().remove() should throw throw new
UnsupportedOperationException()
is it reasonable to add a unit test, that makes sure an
UnsupportedOperationException is thrown?
just saw the second commit on this one. Forget it.
Modified:
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVParser.java
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=1300661r1=1300660r2=1300661view=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 Mar 14 17:43:35 2012
@@ -212,7 +212,9 @@ public class CSVParser implements Iterab
}
}
- public void remove() { }
+ public void remove() {
+ throw new UnsupportedOperationException();
+ }
};
}
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1300699 - /commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
Am 14. März 2012 20:48 schrieb s...@apache.org:
Author: sebb
Date: Wed Mar 14 19:48:12 2012
New Revision: 1300699
URL: http://svn.apache.org/viewvc?rev=1300699view=rev
Log:
Javadoc
Modified:
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
Modified:
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
URL:
http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java?rev=1300699r1=1300698r2=1300699view=diff
==
---
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
(original)
+++
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
Wed Mar 14 19:48:12 2012
@@ -225,7 +225,7 @@ public class CSVFormat implements Serial
}
/**
- * Tells if comments are supported by this format.
+ * Specifies whether comments are supported by this format.
*
* @return tttrue/tt is comments are supported, ttfalse/tt
otherwise
*/
@@ -313,7 +313,8 @@ public class CSVFormat implements Serial
}
/**
- * Tells if unicode escape sequences (i.e span\/spanu1234) are
turned into their corresponding character.
+ * Tells if unicode escape sequences (e.g. span\/spanu1234) are
turned into their corresponding character
how about changing this to [...] (e.g. {@literal \u1234}) are [...]?
would be better readable in the source.
+ * when parsing input.
*
* @return tttrue/tt if unicode escape sequences are interpreted,
ttfalse/tt if they are left as is.
*/
@@ -333,9 +334,9 @@ public class CSVFormat implements Serial
}
/**
- * Tells if the empty lines between the records are ignored.
+ * Specifies whether empty lines between records are ignored when
parsing input.
*
- * @return tttrue/tt if empty lines between records are ignore,
ttfalse/tt if they are turned into empty records.
+ * @return tttrue/tt if empty lines between records are ignored,
ttfalse/tt if they are turned into empty records.
*/
public boolean isEmptyLinesIgnored() {
return emptyLinesIgnored;
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[csv] Why does CSVFormat provide a validate() method instead of validating parameters passed to its constructor?
Hey, the subject of this mail is pretty self-explanatory. Why do we need a package private validate() method, given the fact, that users can not create custom instances (constructor is package private)? You could even argue, that no validation is needed at all, since we are in control of what formats can be created. However I'd say, the validation makes sure that we do not unintentionally create invalid formats. But then validate() can be made private and called at the end of the constructor. Benedikt - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [csv] Why does CSVFormat provide a validate() method instead of validating parameters passed to its constructor?
Am 14. März 2012 22:02 schrieb Emmanuel Bourg ebo...@apache.org:
Le 14/03/2012 21:52, Benedikt Ritter a écrit :
the subject of this mail is pretty self-explanatory. Why do we need a
package private validate() method, given the fact, that users can not
create custom instances (constructor is package private)? You could
even argue, that no validation is needed at all, since we are in
control of what formats can be created. However I'd say, the
validation makes sure that we do not unintentionally create invalid
formats. But then validate() can be made private and called at the end
of the constructor.
Because the format could temporarily be in an invalid state. Something like
this would break (a bit far fetched, I agree):
CSVFormat.DEFAULT.withDelimiter('#').withCommentStart('/');
okay, I understand. But doesn't that make things worse? Users can
create invalid formats, but they can not call validate(), because it
is package private.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [csv] Why does CSVFormat provide a validate() method instead of validating parameters passed to its constructor?
Am 14. März 2012 22:16 schrieb sebb seb...@gmail.com:
On 14 March 2012 21:02, Emmanuel Bourg ebo...@apache.org wrote:
Le 14/03/2012 21:52, Benedikt Ritter a écrit :
the subject of this mail is pretty self-explanatory. Why do we need a
package private validate() method, given the fact, that users can not
create custom instances (constructor is package private)? You could
even argue, that no validation is needed at all, since we are in
control of what formats can be created. However I'd say, the
validation makes sure that we do not unintentionally create invalid
formats. But then validate() can be made private and called at the end
of the constructor.
Because the format could temporarily be in an invalid state. Something like
this would break (a bit far fetched, I agree):
CSVFormat.DEFAULT.withDelimiter('#').withCommentStart('/');
In which case, reversing the order would work.
We would just have to document this as a restriction.
The problem with leaving the validation until later is that it
decouples the cause and effect.
This makes it a bit harder to debug.
It's also simpler if there is a single validation method.
At present some of the setters also perform validation.
I agree with you on this. However, I think it would be better to tie
validation to the object creation. Maybe the Builder Pattern like
shown in Effective Java p. 14-15 is a reasonable solution for this
case? It would be a bit more verbose, but we can be sure that
everything will be validated.
BTW, we should probably reject delimiter == DISABLED.
Also, the DISABLED constant needs to be public (or available via a
public getter) otherwise it's not possible to disable all but the
delimiter.
Using a getter would allow the constant to be changed if it became necessary.
Only if we remove Serializable...
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] Why does CSVFormat provide a validate() method instead of validating parameters passed to its constructor?
Am 14. März 2012 22:33 schrieb Emmanuel Bourg ebo...@apache.org:
Le 14/03/2012 22:25, Benedikt Ritter a écrit :
I agree with you on this. However, I think it would be better to tie
validation to the object creation. Maybe the Builder Pattern like
shown in Effective Java p. 14-15 is a reasonable solution for this
case? It would be a bit more verbose, but we can be sure that
everything will be validated.
That's too verbose, please let's keep this simple API.
okay!
although, I don't find
CSVFormat format =
CSVFormat.defaults().withDelimiter('#').withCommentStart('/').build()
too verbose ;)
Bonne nuit!
Benedikt
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [csv] Headers
Am 15. März 2012 01:58 schrieb Emmanuel Bourg ebo...@apache.org:
There is another alternative, we might replace the records returned as a
String[] by a CSVRecord class able to access the fields by id or by name.
This would be similar to a JDBC resultset (except for the looping logic)
sounds good. This discussion showed, that a record is more than a
String array. So having a specialized class is a good idea.
This avoids the duplication of the parser, which might still be generified
later to support custom beans.
The example becomes:
CSVFormat format = CSVFormat.DEFAULT.withHeader();
for (CSVRecord record : format.parse(in)) {
Person person = new Person();
person.setName(record.get(name));
person.setEmail(record.get(email));
person.setPhone(record.get(phone));
persons.add(person);
}
The record is not a Map to keep it simple, it only exposes 3 methods:
get(int), get(String) and size()
I'm not sure if I understand the approach completely. The Header can
not be accessed as a CSVRecord, right? CSVRecords know the header
values through get(string). What happens if the format does not
support a header? UnsupportedOperationException?
If I got you right, we could use getHeaders() to know, which header
values are available.
Maybe it would be useful to have the record implement iterable as well.
Benedikt
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1300925 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/AccessibleObjectsRegistry.java
Am 15. März 2012 12:59 schrieb sebb seb...@gmail.com: On 15 March 2012 11:26, simonetrip...@apache.org wrote: Author: simonetripodi Date: Thu Mar 15 11:26:25 2012 New Revision: 1300925 URL: http://svn.apache.org/viewvc?rev=1300925view=rev Log: just incrementally built the hashcode in the constructor I wondered why you did not use the java.lang.String approach, but I see the class is used in a HashMap so the hashCode will always be needed. Might be an idea to note this in the ctor? AccessibleObjectDescriptor is a nested private class of the package private AccessibleObjectRegistry. So users will never create AccessibleObjectDescriptors. The class comment says Represents the key to looking up an AccessibleObject by reflection. Would be a bit redundant to add yet another comment to the constructor. - 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] Performance
Am 15. März 2012 13:50 schrieb Gary Gregory garydgreg...@gmail.com: Can you put your perf test code and resources in SVN so I do not have to write on please? Hi Gary, have a look at http://markmail.org/message/x73i3hl63rjqdyfa (I agree with you, that having a clean performance test in SVN would be better) Regards, Benedikt Gary On Thu, Mar 15, 2012 at 8:34 AM, sebb seb...@gmail.com wrote: In my testing, using final class variables for delimiter, escape etc (set in ctor) shaves about 1 sec off the time to read the world town data file compared with accessing these fields inline through the format field. Average time goes from c. 25.5 to c. 24.5 which is a 4% improvement. I suspect this is partly because the fetches are currently in loops rather than any getter overhead. - 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 JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK 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: r1300977 - in /commons/proper/csv/trunk: ./ src/test/java/org/apache/commons/csv/
Am 15. März 2012 14:44 schrieb ggreg...@apache.org:
Author: ggregory
Date: Thu Mar 15 13:44:44 2012
New Revision: 1300977
URL: http://svn.apache.org/viewvc?rev=1300977view=rev
Log:
Update to JUnit 4.10 from 3.8.1.
nice work! how about a static import of org.junit.Assert.* ?
Modified:
commons/proper/csv/trunk/ (props changed)
commons/proper/csv/trunk/pom.xml
commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVFormatTest.java
commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVLexerTest.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/CSVPrinterTest.java
commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/ExtendedBufferedReaderTest.java
Propchange: commons/proper/csv/trunk/
--
--- svn:ignore (original)
+++ svn:ignore Thu Mar 15 13:44:44 2012
@@ -2,3 +2,5 @@
.project
target
.settings
+maven-eclipse.xml
+.externalToolBuilders
Modified: commons/proper/csv/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/commons/proper/csv/trunk/pom.xml?rev=1300977r1=1300976r2=1300977view=diff
==
--- commons/proper/csv/trunk/pom.xml (original)
+++ commons/proper/csv/trunk/pom.xml Thu Mar 15 13:44:44 2012
@@ -16,7 +16,7 @@
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
- version3.8.1/version
+ version4.10/version
scopetest/scope
/dependency
/dependencies
Modified:
commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVFormatTest.java
URL:
http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVFormatTest.java?rev=1300977r1=1300976r2=1300977view=diff
==
---
commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVFormatTest.java
(original)
+++
commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVFormatTest.java
Thu Mar 15 13:44:44 2012
@@ -22,10 +22,12 @@ import java.io.ByteArrayOutputStream;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
-import junit.framework.TestCase;
+import org.junit.Assert;
+import org.junit.Test;
-public class CSVFormatTest extends TestCase {
+public class CSVFormatTest {
+ @Test
public void testImmutalibity() {
CSVFormat format = new CSVFormat('!', '!', '!', '!', true, true,
true, true, \r\n);
@@ -39,91 +41,94 @@ public class CSVFormatTest extends TestC
format.withEmptyLinesIgnored(false);
format.withUnicodeEscapesInterpreted(false);
- assertEquals('!', format.getDelimiter());
- assertEquals('!', format.getEncapsulator());
- assertEquals('!', format.getCommentStart());
- assertEquals('!', format.getEscape());
- assertEquals(\r\n, format.getLineSeparator());
-
- assertEquals(true, format.isLeadingSpacesIgnored());
- assertEquals(true, format.isTrailingSpacesIgnored());
- assertEquals(true, format.isEmptyLinesIgnored());
- assertEquals(true, format.isUnicodeEscapesInterpreted());
+ Assert.assertEquals('!', format.getDelimiter());
+ Assert.assertEquals('!', format.getEncapsulator());
+ Assert.assertEquals('!', format.getCommentStart());
+ Assert.assertEquals('!', format.getEscape());
+ Assert.assertEquals(\r\n, format.getLineSeparator());
+
+ Assert.assertEquals(true, format.isLeadingSpacesIgnored());
+ Assert.assertEquals(true, format.isTrailingSpacesIgnored());
+ Assert.assertEquals(true, format.isEmptyLinesIgnored());
+ Assert.assertEquals(true, format.isUnicodeEscapesInterpreted());
}
+ @Test
public void testMutators() {
CSVFormat format = new CSVFormat('!', '!', '!', '!', true, true,
true, true, \r\n);
- assertEquals('?', format.withDelimiter('?').getDelimiter());
- assertEquals('?', format.withEncapsulator('?').getEncapsulator());
- assertEquals('?', format.withCommentStart('?').getCommentStart());
- assertEquals(?, format.withLineSeparator(?).getLineSeparator());
- assertEquals('?', format.withEscape('?').getEscape());
-
- assertEquals(false,
format.withLeadingSpacesIgnored(false).isLeadingSpacesIgnored());
- assertEquals(false,
format.withTrailingSpacesIgnored(false).isTrailingSpacesIgnored());
- assertEquals(false,
format.withSurroundingSpacesIgnored(false).isLeadingSpacesIgnored());
- assertEquals(false,
format.withSurroundingSpacesIgnored(false).isTrailingSpacesIgnored());
- assertEquals(false,
format.withEmptyLinesIgnored(false).isEmptyLinesIgnored());
- assertEquals(false,
Re: [csv] Why does CSVFormat provide a validate() method instead of validating parameters passed to its constructor?
Am 14. März 2012 22:47 schrieb sebb seb...@gmail.com:
On 14 March 2012 21:40, Benedikt Ritter benerit...@googlemail.com wrote:
Am 14. März 2012 22:33 schrieb Emmanuel Bourg ebo...@apache.org:
Le 14/03/2012 22:25, Benedikt Ritter a écrit :
I agree with you on this. However, I think it would be better to tie
validation to the object creation. Maybe the Builder Pattern like
shown in Effective Java p. 14-15 is a reasonable solution for this
case? It would be a bit more verbose, but we can be sure that
everything will be validated.
That's too verbose, please let's keep this simple API.
okay!
although, I don't find
CSVFormat format =
CSVFormat.defaults().withDelimiter('#').withCommentStart('/').build()
too verbose ;)
Agree entirely.
And parse and format could perform an implicit build().
It would also allow one to eliminate the additional instance creation.
How about you Emmanuel? Could sebb convince you? ;-) How about this:
I'll create a patch and attach it to JIRA. Then we'll have a better
basis for discussion.
Bonne nuit!
Gute Nacht ?
Benedikt
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
[csv] Improving readability in CSVLexer
Hey, I'm thinking of ways to improve the readability of CSVLexer. I think that it might be easier to improve performance if the code is easier to understand. Here is, what I think can be improved: 1. eliminate Token input parameter on nextToken() To me it looks like the token input parameter on nextToken() has the purpose of sparing object creation. How about a private field 'currentToken' that can be reused. No method parameters are better than one method parameter :) 2. add additional convenience methods Right now we have some methods for char handling like isEndOfFile(c). There are some methods missing like isDelimiter(c) or isEncapsulator(c). There is not much to say about this. I just think that isDelimiter(c) is slightly easier to understand than c == format.getDelimiter(). 3. eliminate input parameter c on readEscape (and rename it ?) Right now we have to pass an int to readEscape, but the method does not use that parameter. So why do we keep it? Also the method does not really read an escape. It assumes, that is is called after a / and then returns the delimiter for a letter. 4. Get rid of those nasty while(true) loops! There are several while true loops. It is really hard to see what is going on, because you can not exactly see when a loop ends. The worst example for this is encapsulatedTokenLexer. It has an outer while(true) loop with a nested inner loop, that may return a token, terminating both loops. I've tried to eliminate those while true loops, but without success. If no one objects, I'd like to create patches for 1. 2. I leave 3. and 4. for discussion... Regards, Benedikt - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [csv] Why does CSVFormat provide a validate() method instead of validating parameters passed to its constructor?
Am 16. März 2012 23:36 schrieb Emmanuel Bourg ebo...@apache.org: Choice is good I agree. Commons CSV will also support annotated POJO, that will give two ways to use the API. Are we still talking about how to create CSVFormat instances? Benedikt Emmanuel Bourg Le 16/03/2012 22:26, Simone Tripodi a écrit : Hi all, whatever name/pattern is called what we intend to apply, the result doesn't change :P Jokes a part, given the past experience of Digester3, as reported by Matt and James, I can suggest you to not limit to users the possibilities to chose their preferred approaches. Digester3 - which of course has a larger set of APIs - allows users configuring it with four APIs set: * plain old Digester2.X addRule() alike methods; * the RulesBinder fluent APIs; * Annotated POJOs, built on top of RulesBinder; * XML descriptors, built on top of RulesBinder. no restrictions - just provide the n API layers that users want/need on top of one in order to centralize the errors and make them satisfied (which is he most important side, IMHO). When developing Digester3, I wondered who would have used the xmlrules today: pooff, magically a users not only is using it, he's also contributing on making it betetr on supporting multi-thread environments. So, concluding: instead of choosing which approach has to be applied, just apply both as Seb is proposing. Just my 0.02 cents, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Fri, Mar 16, 2012 at 5:40 PM, James Carman jcar...@carmanconsulting.com wrote: Did I say they were the same? On Mar 16, 2012 12:22 PM, Emmanuel Bourgebo...@apache.org wrote: Le 16/03/2012 13:34, James Carman a écrit : +1 for builder pattern and fluent API Fluent API != Builder Pattern They are similar because they use method chaining, but that's not equivalent. http://martinfowler.com/bliki/**FluentInterface.htmlhttp://martinfowler.com/bliki/FluentInterface.html http://en.wikipedia.org/wiki/**Fluent_interfacehttp://en.wikipedia.org/wiki/Fluent_interface http://en.wikipedia.org/wiki/**Builder_patternhttp://en.wikipedia.org/wiki/Builder_pattern Emmanuel Bourg --**--**- 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 - 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: r1301852 - in /commons/proper/csv/trunk/src: main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Am 17. März 2012 13:12 schrieb sebb seb...@gmail.com:
On 17 March 2012 01:39, ebo...@apache.org wrote:
Author: ebourg
Date: Sat Mar 17 01:39:04 2012
New Revision: 1301852
URL: http://svn.apache.org/viewvc?rev=1301852view=rev
Log:
Header support (CSV-65)
Added:
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVRecord.java
Modified:
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVParser.java
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/package.html
commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVFormatTest.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/CSVPrinterTest.java
snip/
Added:
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=1301852view=auto
==
---
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVRecord.java
(added)
+++
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVRecord.java
Sat Mar 17 01:39:04 2012
@@ -0,0 +1,87 @@
snip/
+ *
+ * @author Emmanuel Bourg
The ASF deprecates @author comments in code; these should go in the
pom / release notes / changes instead.
+ */
+public class CSVRecord implements Serializable, IterableString {
+
Does the class need to be public?
Yes, otherwise CSVParser.getRecords() would be rather senseless. Users
wouldn't not be able to assign Records to a variable.
Does it need to be Serializable?
-
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: r1303488 - /commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
What about the Builder pattern we discussed lately? Several people
have expressed their feels for that solution.
Am 21. März 2012 19:20 schrieb s...@apache.org:
Author: sebb
Date: Wed Mar 21 18:20:05 2012
New Revision: 1303488
URL: http://svn.apache.org/viewvc?rev=1303488view=rev
Log:
CSV-74 - CSVFormat definitions are difficult to read and maintain
Modified:
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
Modified:
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
URL:
http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java?rev=1303488r1=1303487r2=1303488view=diff
==
---
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
(original)
+++
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
Wed Mar 21 18:20:05 2012
@@ -51,8 +51,23 @@ public class CSVFormat implements Serial
*/
static final char DISABLED = '\ufffe';
+ /**
+ * Starting format with no settings defined; used for creating other
formats from scratch.
+ */
+ private static CSVFormat PRISTINE =
+ new CSVFormat(DISABLED, DISABLED, DISABLED, DISABLED, false,
false, false, null, null);
+
/** Standard comma separated format as defined by a
href=http://tools.ietf.org/html/rfc4180;RFC 4180/a. */
- public static final CSVFormat DEFAULT = new CSVFormat(',', '',
DISABLED, DISABLED, true, true, true, CRLF, null);
+ public static final CSVFormat DEFAULT =
+ PRISTINE.
+ withDelimiter(',')
+ .withEncapsulator('')
+ .withLeadingSpacesIgnored(true)
+ .withTrailingSpacesIgnored(true)
+ .withEmptyLinesIgnored(true)
+ .withLineSeparator(CRLF)
+ ;
+
/**
* Excel file format (using a comma as the value delimiter).
@@ -65,10 +80,23 @@ public class CSVFormat implements Serial
*
* preCSVFormat fmt = CSVFormat.EXCEL.withDelimiter(';');/pre
*/
- public static final CSVFormat EXCEL = new CSVFormat(',', '', DISABLED,
DISABLED, false, false, false, CRLF, null);
+ public static final CSVFormat EXCEL =
+ PRISTINE
+ .withDelimiter(',')
+ .withEncapsulator('')
+ .withLineSeparator(CRLF)
+ ;
/** Tab-delimited format, with quote; leading and trailing spaces
ignored. */
- public static final CSVFormat TDF = new CSVFormat('\t', '', DISABLED,
DISABLED, true, true, true, CRLF, null);
+ public static final CSVFormat TDF =
+ PRISTINE
+ .withDelimiter('\t')
+ .withEncapsulator('')
+ .withLeadingSpacesIgnored(true)
+ .withTrailingSpacesIgnored(true)
+ .withEmptyLinesIgnored(true)
+ .withLineSeparator(CRLF)
+ ;
/**
* Default MySQL format used by the ttSELECT INTO OUTFILE/tt and
@@ -78,7 +106,12 @@ public class CSVFormat implements Serial
*
* @see a
href=http://dev.mysql.com/doc/refman/5.1/en/load-data.html;http://dev.mysql.com/doc/refman/5.1/en/load-data.html/a
*/
- public static final CSVFormat MYSQL = new CSVFormat('\t', DISABLED,
DISABLED, '\\', false, false, false, \n, null);
+ public static final CSVFormat MYSQL =
+ PRISTINE
+ .withDelimiter('\t')
+ .withEscape('\\')
+ .withLineSeparator(\n)
+ ;
/**
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [csv] Improving readability in CSVLexer
Hey, I've tried to remove the Token input parameter in CSVLexer.nextToken(). First by creating ne new Token on every invocation of nextToken(). That slowed execution of that method by about 100ms. So I added a private Token field to CSVLexer, that only get's initiated once. But that solution was also slower than the one we have now. I'm not sure what to do now. Any suggestions? Shall I create a patch for you to review? Regards, Benedikt Am 16. März 2012 17:06 schrieb Emmanuel Bourg ebo...@apache.org: Le 16/03/2012 17:01, Emmanuel Bourg a écrit : 2. add additional convenience methods Right now we have some methods for char handling like isEndOfFile(c). There are some methods missing like isDelimiter(c) or isEncapsulator(c). There is not much to say about this. I just think that isDelimiter(c) is slightly easier to understand than c == format.getDelimiter(). Sorry I misread your phrase. Actually removing these methods resulted in a slower parsing. So yes give it a try. 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] Improving readability in CSVLexer
Am 22. März 2012 00:19 schrieb sebb seb...@gmail.com: On 21 March 2012 19:16, Benedikt Ritter benerit...@googlemail.com wrote: Hey, I've tried to remove the Token input parameter in CSVLexer.nextToken(). First by creating ne new Token on every invocation of nextToken(). That slowed execution of that method by about 100ms. 100ms per iteration? Or for the entire file? for parsing the hole file So I added a private Token field to CSVLexer, that only get's initiated once. But that solution was also slower than the one we have now. I'm not sure what to do now. Any suggestions? Shall I create a patch for you to review? It's not necessary to change that call, so let's leave it. It was plan of our plan to split up the parsing logic in smaller methods to make it easier for the compiler to optimize the code. I thought it may be easier if we got rid of that input parameter. Regards, Benedikt Am 16. März 2012 17:06 schrieb Emmanuel Bourg ebo...@apache.org: Le 16/03/2012 17:01, Emmanuel Bourg a écrit : 2. add additional convenience methods Right now we have some methods for char handling like isEndOfFile(c). There are some methods missing like isDelimiter(c) or isEncapsulator(c). There is not much to say about this. I just think that isDelimiter(c) is slightly easier to understand than c == format.getDelimiter(). Sorry I misread your phrase. Actually removing these methods resulted in a slower parsing. So yes give it a try. 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1303878 - /commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/PerformanceTest.java
Am 22. März 2012 17:28 schrieb s...@apache.org:
Author: sebb
Date: Thu Mar 22 16:28:47 2012
New Revision: 1303878
URL: http://svn.apache.org/viewvc?rev=1303878view=rev
Log:
Allow testing of dynamically loaded CSVLexers
I'm not sure if I understand where you are going with this. Don't you
think it's a bit over engineered to put reflection into the
performance test? Are you doing that, because you want to test new
CSVLexer implementations using the CSVLexer1? The performance test
starts to get complex. Maybe you should explain to the ML, what you
are planning?
Benedikt
Modified:
commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/PerformanceTest.java
Modified:
commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/PerformanceTest.java
URL:
http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/PerformanceTest.java?rev=1303878r1=1303877r2=1303878view=diff
==
---
commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/PerformanceTest.java
(original)
+++
commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/PerformanceTest.java
Thu Mar 22 16:28:47 2012
@@ -20,6 +20,8 @@ package org.apache.commons.csv;
import java.io.BufferedReader;
import java.io.FileReader;
import java.io.IOException;
+import java.lang.reflect.Constructor;
+import java.lang.reflect.InvocationTargetException;
/**
* Basic test harness.
@@ -86,10 +88,14 @@ public class PerformanceTest {
testCSVLexer(false, test);
} else if (lexnew.equals(test)) {
testCSVLexer(true, test);
+ } else if (test.startsWith(CSVLexer)) {
+ testCSVLexer(false, test);
} else if (extb.equals(test)) {
testExtendedBuffer(false);
} else if (exts.equals(test)) {
testExtendedBuffer(true);
+ } else {
+ System.out.println(Invalid test name: +test);
}
}
}
@@ -198,11 +204,26 @@ public class PerformanceTest {
show();
}
+
+ private static ConstructorLexer getLexerCtor(String clazz) throws
Exception {
+ @SuppressWarnings(unchecked)
+ ClassLexer lexer = (ClassLexer)
Class.forName(org.apache.commons.csv.+clazz);
+ ConstructorLexer ctor = lexer.getConstructor(new
Class?[]{CSVFormat.class, ExtendedBufferedReader.class});
+ return ctor;
+ }
+
private static void testCSVLexer(final boolean newToken, String test)
throws Exception {
Token token = new Token();
+ String dynamic = ;
for (int i = 0; i max; i++) {
- final BufferedReader reader = getReader();
- Lexer lexer = new CSVLexer(format, new
ExtendedBufferedReader(reader));
+ final ExtendedBufferedReader input = new
ExtendedBufferedReader(getReader());
+ Lexer lexer = null;
+ if (test.startsWith(CSVLexer)) {
+ dynamic=!;
+ lexer = getLexerCtor(test).newInstance(new Object[]{format,
input});
+ } else {
+ lexer = new CSVLexer(format, input);
+ }
int count = 0;
int fields = 0;
long t0 = System.currentTimeMillis();
@@ -229,8 +250,8 @@ public class PerformanceTest {
} while (!token.type.equals(Token.Type.EOF));
Stats s = new Stats(count, fields);
- reader.close();
- show(test, s, t0);
+ input.close();
+ show(lexer.getClass().getSimpleName()+dynamic+ +(newToken ?
new : reset), s, t0);
}
show();
}
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[csv] Rename methods on XXXLexer methods on CSVLexer
Hey, how about renaming CSVLexer.simpleTokenLexer() and CSVLexer.encapsulatedTokenLexer(), so that the method names express what the methods do? For example simpleTokenLexer() could be renamed to parseSimpleToken or parseSimpleTokenContent. Likewise encapsulatedTokenLexer() could be renamed to parseEncapsulatedToken or parseEncapsulatedTokenContent. Benedikt - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [csv] Rename methods on XXXLexer methods on CSVLexer
Am 29. März 2012 22:07 schrieb sebb seb...@gmail.com: On 29 March 2012 20:45, Benedikt Ritter benerit...@googlemail.com wrote: Hey, how about renaming CSVLexer.simpleTokenLexer() and CSVLexer.encapsulatedTokenLexer(), so that the method names express what the methods do? For example simpleTokenLexer() could be renamed to parseSimpleToken or parseSimpleTokenContent. Likewise encapsulatedTokenLexer() could be renamed to parseEncapsulatedToken or parseEncapsulatedTokenContent. They are private methods so the name is arbitrary. I also think the current names are OK. I'm just saying, that method names usually are verbs (or contain verbs). They describe something that gets done be a method. Nouns are used for classes. It feels strange to have a method that is a lexer. I don't think that private method names are arbitrary. They are far less important than public methods. It's a matter of readability to chose good names for private methods as well. I'm not sure I agree that the methods are parsers. They are closer to lexers. If the methods don't parse, how about scan? 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: [ALL]Can you share the codeformater.xml and codetemplates.xml in eclipse
Since configurations may change over time it would be better to put them in SVN. Benedikt 2012/5/31 sebb seb...@gmail.com: On 31 May 2012 22:13, Gary Gregory garydgreg...@gmail.com wrote: We need to put this or some commons wide convention in SVN... where? How about commons-parent? ide/eclipse/? Or stick it on the Wiki. Gary On Thu, May 17, 2012 at 6:26 AM, Luc Maisonobe l...@spaceroots.org wrote: Le 17/05/2012 04:47, Love Yao a écrit : I guess some of the commons-team must use Eclipse to coding, and for your using CheckStyle, there should being IDE config, so Can you share the codeformater.xml and codetemplates.xml in eclipse. I do not find them in SVN,thanks. See http://people.apache.org/~luc/Apache-commons.xml best regards, Luc - 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 JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] How to use a class from the test source tree?
Hi, 2012/6/13 Gilles Sadowski gil...@harfang.homelinux.org: Hi. Is there a way for an application to depend on the classes defined in the test subtree of the code repository? If the component releases the test jar, then it should be possible. It seems that it's not released as a JAR (probably only in the zip/tar and source archive). But if the test code is more generally useful, perhaps it should be moved to the java subtree. I'd like to make it easy to use PerfTestUtils outside of the CM development environment. Is it OK to move it to main? Before doing so, I also expected that more people would have a look at it, and agree on the methodology (or suggest ways to improve it) and API. When I move it, should it go to the top-level package o.a.c.m? Or maybe into util? Or even a new util/perf subpackage (to separate utilities used by the CM code from utilities used to test the code's performance? I don't know, to me it feels rather strange to add a TestPerfUtil to the public API of a mathematical library. OTOH TestPerfUtils looks to specific to be used outside the context of CM (it uses classes defined in CM). I see two solutions: 1. if you need it just for one project, you could simply copy the class to that project in the test tree 2. if you need it for several projects and there are additional useful classes in the test tree that are concerned with tests in context of CM, a new component could be created that defines a dependency to CM. This dependency (commons-math-testutils ?!) could then be added to what ever project in the test scope. Benedikt Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] How to use a class from the test source tree?
Hi again, 2012/6/13 Gilles Sadowski gil...@harfang.homelinux.org: On Wed, Jun 13, 2012 at 12:34:51PM +0200, Benedikt Ritter wrote: Hi, 2012/6/13 Gilles Sadowski gil...@harfang.homelinux.org: Hi. Is there a way for an application to depend on the classes defined in the test subtree of the code repository? If the component releases the test jar, then it should be possible. It seems that it's not released as a JAR (probably only in the zip/tar and source archive). But if the test code is more generally useful, perhaps it should be moved to the java subtree. I'd like to make it easy to use PerfTestUtils outside of the CM development environment. Is it OK to move it to main? Before doing so, I also expected that more people would have a look at it, and agree on the methodology (or suggest ways to improve it) and API. When I move it, should it go to the top-level package o.a.c.m? Or maybe into util? Or even a new util/perf subpackage (to separate utilities used by the CM code from utilities used to test the code's performance? I don't know, to me it feels rather strange to add a TestPerfUtil to the public API of a mathematical library. I agree. [That's why I put the class where it is.] OTOH TestPerfUtils looks to specific to be used outside the context of CM (it uses classes defined in CM). I don't understand that. It's a (mini-)benchmarking tool; it can be used to time any code, not just CM routines. PerfTestUtils defines imports: import org.apache.commons.math3.stat.descriptive.SummaryStatistics; import org.apache.commons.math3.stat.descriptive.StatisticalSummary; import org.apache.commons.math3.exception.MathIllegalStateException; it can not be used without having CM on the classpath. That's what i meant ;-) I see two solutions: 1. if you need it just for one project, you could simply copy the class to that project in the test tree No. The purpose is to provide a tool to anyone who claims that changing X in the CM code will improve performance, so that the claim is backed by actual numbers. In this case one will have to check out the hole CM anyway, I guess? 2. if you need it for several projects and there are additional useful classes in the test tree that are concerned with tests in context of CM, a new component could be created that defines a dependency to CM. This dependency (commons-math-testutils ?!) could then be added to what ever project in the test scope. A clean solution, but I don't think that there is enough code to be worth the burden of a separate project. A third solution is to indeed publish a JAR composed of the classes in the test subtree of the repository, as hinted at by Sebb. If it's OK, could someone please make the necessary changes (both for producing official releases and for daily snapshots)? I agree. regards, Benedikt Thanks, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[BeanUtils2] Thoughts about the API
Hi,
while working on BU2, I was thinking about the API and what may be improved.
Exceptions:
Right now a lot of API methods just populate the checked reflection
exceptions like InvocationTargetException from the native java
reflection API. This dooms Java 6 users to write code like:
try {
Bean clone = on( original ).cloneBean();
} catch (IllegalAccessException iae) {
// what to do here?
} catch (InstantiationException ie) {
// and here?
} catch (IntrospectionException ie2) {
// and here?
} catch (InvocationTargetException ite) {
// and here?
} catch (NoSuchMethodException nsme) {
// and here?
}
The missing javaDoc for some exceptions shows, that I myself was
unsure in what cases some exceptions will occure.
To overcome this, users may implement something like:
try {
Bean clone on( original ).cloneBean();
} catch (Exception e) {
// now nothing can go wrong, right?
}
The problem is, that this will swallow useful RuntimeExeptions (for
example like IllegalArgumentException when passing null to a primtive
property).
I see several solutions:
1. update BU2 to Java 7. We could make use of
ReflectiveOperationException [1]. Beside that users can use the new
multi catch blocks.
2. Wrap checked exceptions into RuntimeExceptions. The question is,
what a user can do to recover from one of those exceptions. Only if
there is something the user can do, it would make sense to throw a
checked exception.
3. leave everything as is
All tree solution have pros and cons. I think that having a method
like cloneBean() throw 5 checked exceptions feels rather clumsy. So I
prefer the second option. What do you think?
Processing of Annotations:
Do we have access of annotations on our agenda? I can imagine something like:
on ( bean.getClass() ).getAnnotation( annotationName ).fromMethod(
methodName ).getValue( valueName );
The exact API would have to be discussed. But in general, I think this
fits nicely into BU2.
Changing of MappedProperty(Getter|Setter)Accessor:
A while ago we decided to shorten method names as much as possible.
For example we changed BeanAccessor.getProperty(String propertyName)
to BeanAccessor.get(String propertyName). However, we did not change
the methods on MappedProperty(Getter|Setter)Accessor and
ArgumentsAccessor, all three classes define withXXX as methods.
How do you feel about changing
MappedProperty(Getter|Setter)Accessor.withKey(String key)
to
MappedProperty(Getter|Setter)Accessor.for(String key)
so that ArgumentsAccessor.withArguments( Argument... Arguments )
can be changed to
ArgumentsAccessor.with( Argument... Arguments )
This would result in a fluent call like:
on( bean ).getMapped( mappedProperty ).for( theKey );
and
on( bean ).setMapped( mappedProperty ).for( theKey ).with( value );
and
on (bean ).invoke( methodName ).with( value1, value2, value3);
Regards,
Benedikt
[1]
http://docs.oracle.com/javase/7/docs/api/java/lang/ReflectiveOperationException.html
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [BeanUtils2] Thoughts about the API
Hi, I agree with what you said. - Annotation processing: let's keep that in mind, and come back to it later. Simo, can you create the wiki page for us? - Renaming methods: I hope that I get the time to create a patch this weekend - Wrapper Exceptions: I thing we should discuss, how a exception hierarchy could look like. I'll make a suggestion ASAP. Regards, Benedikt 2012/6/15 Simone Tripodi simonetrip...@apache.org: Thanks a lot for monitoring BU2 James, and thanks for the feedbacks! this sounds to be the way to go! now waiting for patches from Benedikt :) best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Fri, Jun 15, 2012 at 1:05 PM, James Carman ja...@carmanconsulting.com wrote: On Fri, Jun 15, 2012 at 1:50 AM, Simone Tripodi simonetrip...@apache.org wrote: 2. Wrap checked exceptions into RuntimeExceptions. The question is, what a user can do to recover from one of those exceptions. Only if there is something the user can do, it would make sense to throw a checked exception. this is currently the option I'd prefer! +1! This is one thing I hate about BeanUtils. I really hate having to catch all these exceptions and every project where I use BU, I usually end up wrapping the calls to do this very thing, since there's really nothing you can do about it typically and it would indicate a programming error, not some runtime condition which you can code around. - 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] Thoughts about the API
2012/6/15 James Carman ja...@carmanconsulting.com: On Fri, Jun 15, 2012 at 9:39 AM, Benedikt Ritter benerit...@googlemail.com wrote: - Wrapper Exceptions: I thing we should discuss, how a exception hierarchy could look like. I'll make a suggestion ASAP. I don't want to duplicate the hierarchy. I would say start with a generic exception type for now. If folks ask for more specific subtypes later, we can add them. Would adding more specific RuntimeExceptions later break bc? I think no, because RuntimeExceptions don't have to be part of the method signature. But I'm not sure :-) thanks, 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
[BeanUtils2] Some proposals for an exception name
Hi, following up on the thread where we discussed about the current state of the API [1], I want to discuss how to name the generic RuntimeException we talked about. Here are some proposals: 1. BeanUtilsException 2. BeanUtilsReflectionException 3. ReflectionException 4. ReflectiveAcessException My personal favorite is ReflectionException. I don't think, that we should prefix classes wie BeanUtils*, because this information is contained in the fully qualified class name. The problem is, that there is already a ReflectionException in javax [2]. So I guess we can not use that name? Regards, Benedikt [1] http://markmail.org/message/yetl76y734dnt5zz [2] http://docs.oracle.com/javase/1.5.0/docs/api/javax/management/ReflectionException.html - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [BeanUtils2] Thoughts about the API
I just realized, that we cannot call a method MappedPropertyAccessor.for(String key) - for is a reserved keyword ;-) How about: MappedPropertyAcessor.forKey(String key) and ArgumentsAcessor.with(Argument... Arguments) Benedikt 2012/6/16 Simone Tripodi simonetrip...@apache.org: +1 to James for both topics, let's start from a basic exception - naming proposals are welcome. I'll create the wiki page later after dinner - that WE is too much sunny to stay at home ;) best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Fri, Jun 15, 2012 at 5:48 PM, James Carman ja...@carmanconsulting.com wrote: It shouldn't. If you're catching the superclass (for instance BeanUtilsReflectionException) and later we start to throw BeanUtilsInstantiationException which extends BeanUtilsReflectionException, I don't think you'll run into problems. On Fri, Jun 15, 2012 at 10:26 AM, Benedikt Ritter benerit...@googlemail.com wrote: 2012/6/15 James Carman ja...@carmanconsulting.com: On Fri, Jun 15, 2012 at 9:39 AM, Benedikt Ritter benerit...@googlemail.com wrote: - Wrapper Exceptions: I thing we should discuss, how a exception hierarchy could look like. I'll make a suggestion ASAP. I don't want to duplicate the hierarchy. I would say start with a generic exception type for now. If folks ask for more specific subtypes later, we can add them. Would adding more specific RuntimeExceptions later break bc? I think no, because RuntimeExceptions don't have to be part of the method signature. But I'm not sure :-) thanks, 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
[BeanUtils2] Do we still need the internal and the transformers package?
Hi, I remember, that we added the internal package, because we had the need to split up the code base. Looking at the code base now, I don't see any reason for the internal package. Can we move Assertions back to the main package and remove the internal package? And what do we need the transformer for? It has been there from the beginning, but we never used it. Is it an artifact from BeanUtils1 that can be dropped as well? Thanks, Benedikt - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [BeanUtils2] Some proposals for an exception name
Hi, I've started to implement BeanReflectionException and I want to take the approach Simone suggested with the ErrorMessage from Digester. Now I have a problem: If I want to pass the throwable cause as well, that parameter has to be before the varargs argument. This would result in the following constructor signature: public BeanReflectionException( String messagePattern, Throwable cause, Object... arguments ) or public BeanReflectionException( Throwable cause, String messagePattern, Object... arguments ) I don't like either, because the super constructor declares throwable to be the last parameter. Now I could implement a builder for BeanReflectionException that allows to construct BeanReflectionExcetion in a fluent manner: throw BeanReflectionException.withMessagePattern( pattern ).withArguments( arguments ).withCause( cause ).create(); But this seems to be a bit over-engineered for an exceptions that will most probably never be constructed in user code. So I think I'll go with public BeanReflectionException( Throwable cause, String messagePattern, Object... arguments ) What do you think? Benedikt 2012/6/18 Simone Tripodi simonetrip...@apache.org: Sounds even better! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Jun 18, 2012 at 12:33 PM, James Carman jcar...@carmanconsulting.com wrote: BeanReflectionException? Sent from tablet device. Please excuse typos and brevity. On Jun 18, 2012 4:30 AM, Simone Tripodi simonetrip...@apache.org wrote: Guten morgen, Bene, My personal favorite is ReflectionException. I don't think, that we should prefix classes wie BeanUtils*, because this information is contained in the fully qualified class name. +1 I wouldn't happy at all to add a BeanUtilsException, ReflectionException sounds the good candidate for me as well, with following potential hierarchy: ReflectionException - PropertyNotFoundException - ReaderMethodNotFoundException - WriterMethodNotFoundException - ... The problem is, that there is already a ReflectionException in javax [2]. So I guess we can not use that name? I don't see where the issue could be, since full qualified names would be different: javax.management.ReflectionException != org.apache.commons.beanutils2.ReflectionException there are no chances for a naming conflict. A suggestion: we are often using the String.format() method to format Exception messages - which is very good, IMHO - and since we are introducing a new Exception we can take advantage for reducing its use, centralizing the message format in the new exception itself, have a look at the Digester's ErrorMessage http://s.apache.org/wiR Alles gute und dankeshön, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.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: [BeanUtils2] Do we still need the internal and the transformers package?
2012/6/19 Simone Tripodi simonetrip...@apache.org: Hello, I remember, that we added the internal package, because we had the need to split up the code base. Looking at the code base now, I don't see any reason for the internal package. Can we move Assertions back to the main package and remove the internal package? yes, I am taking care of it (not sure that action worths an issue) And what do we need the transformer for? It has been there from the beginning, but we never used it. Is it an artifact from BeanUtils1 that can be dropped as well? We've haven't used it but we could (should?) do - BU supports the useful feature of properties settings via Converters, that means that someone could chose to pass a String to set an Integer. okay, I understand The transformer package was initially designed for that purpose - we never used it because of lack of time, not because it is not useful :P thanks for the info :-) best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.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] Thoughts about the API
2012/6/18 Simone Tripodi simonetrip...@apache.org: +1 to 'of' short to type and intuitive! Thanks Matt for the valuable feedbacks! I'll implement that after I'm finished with replacing the exceptions. Benedikt best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.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] Some proposals for an exception name
2012/6/19 Simone Tripodi simonetrip...@apache.org: The point is with Property %s not found in %s type you're embedding the relevant data in the message text and a client would have to parse the text if a special handling is required. I would never force poor users parsing the exception message to understand what is wrong - I would add getters to the exception to retrieve both propertyName/targetClass of PropertyNotFoundException, in the same way users are used to invoke the getCause() method. Apologize for not having been explicit on this! I'm working on this issue and I've created a hierachy like this: BeanReflectionException - PropertyNotFoundException (Wraps IntrospectionException) - PropertyNotReadableException (Wraps NoSuchMethodExcpetion) - PropertyNotWirteableException (Wraps NoSuchMethodException) - PropertyNotAccessibleException (Wraps IllegalAccessException) - MethodInvocationException (Wraps InvocationTargetException) - - PropertySetterInvocationException (Wraps InvocationTargetException) - - PropertyGetterInvocationExcpetion (Wraps InvocationTargetExcpetion) Right now I've a lot of code duplication, that I have to get rid of before I create the new patch. Beside that there is one other issue I'm not exactly sure how to deal with. In my first patch attached to https://issues.apache.org/jira/browse/SANDBOX-423 I've catched all exceptions in DefaultBeanAcessor.get(String propertyName). That results in a lot of try catch code in that class. Now I'm thinking that it might be a better approach to handle exception where they first appeared. For example we could catch the NoSuchMethodException in DefaultBeanProperties. That would scatter the exception handling everywhere around in the code, but it would reduce the overhead in DefaultBeanAcessor. What do you think? Benedikt -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.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
[BeanUtils2] In what cases can we expect to see an IllegalAccessException?
Hi, I'm still working on https://issues.apache.org/jira/browse/SANDBOX-423 and I wanted to test if all the new exception get thrown correctly. For that reason I implemented a new class - ExceptionThrowingTestBean that properties and methods that throw exceptions when they get called. That way I can test if the InvocationTargetException gets wrapped correctly in. I also implemented getters and setters with default, protected and private visibility. I expected to get an IllegalAccessException wrapped in a PropertyNotAccessibleException. Instead I got: java.lang.Exception: Unexpected exception, expectedorg.apache.commons.beanutils2.exception.PropertyNotAccessibleException but wasorg.apache.commons.beanutils2.exception.PropertyNotFoundException at org.junit.internal.runners.statements.ExpectException.evaluate(ExpectException.java:31) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) Caused by: org.apache.commons.beanutils2.exception.PropertyNotFoundException: Property privateProperty not found in type org.apache.commons.beanutils2.testbeans.ExceptionThrowingTestBean at org.apache.commons.beanutils2.DefaultBeanAccessor.get(DefaultBeanAccessor.java:73) at org.apache.commons.beanutils2.GetPropertyTestCase.getPrivateProperty(GetPropertyTestCase.java:93) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.ExpectException.evaluate(ExpectException.java:22) ... 17 more Caused by: java.beans.IntrospectionException: Property 'privateProperty' does not exist in bean of type org.apache.commons.beanutils2.testbeans.ExceptionThrowingTestBean at org.apache.commons.beanutils2.DefaultBeanProperties.getPropertyDescriptor(DefaultBeanProperties.java:106) at org.apache.commons.beanutils2.DefaultBeanProperties.getReadPropertyMethod(DefaultBeanProperties.java:119) at org.apache.commons.beanutils2.DefaultBeanAccessor.get(DefaultBeanAccessor.java:65) ... 27 more I believe this is, because somewhere deep inside AccessibleObjectsRegistry everthing that is not public will be ignored (see line 352 in that class). So the AccessibleObjectsRegistry returns null for a property getter that is not accessible. Is this an acceptable behavior or do we have to change that? I believe that even if the user code has access to a method/property/constructor, the BU2 code won't have access. This is because client code may reside in the same class (private visibility), package (default visibility) or in an inheriting class (protected visibility), but the code that actually calls the methods is in BU2 and won't have access. Am I right? What do we do about that? My suggestion would be instead of returning null (line 354) in AccessibleObjectsRegistry, we could throw an IllegalAccessException that could be caught and wrapped later on. What do you think? Regrads, Benedikt
Re: [BeanUtils2] In what cases can we expect to see an IllegalAccessException?
Hi Simo, 2012/6/21 Simone Tripodi simonetrip...@apache.org: Hi Bene, I'll need some time to read you email, I am close to a deadline and still have few task to complete. no problem! In the meanwhile, I'd sugest you to move exceptions outside the `exception` package and drop it - exceptions should be packaged at APIs level, not by their nature. Have a look, just to mention a good example, at IOException[1] and (some of) derivates - they are in the java.io, not java.io.exception java.io.InputStream#read() throws java.io.IOException Of course, there are also samples (not in the JDK that I know) where exceptions are packaged in `exception(s)` package but... would you move interfaces in the `interface(s)`? I wouldn't :P Just kidding ;) Many thanks for this suggestion! I never thought about it from that side, but you're absolutely right. I'll change it. Benedikt best and thanks in advance for the hard work, -Simo [1] http://docs.oracle.com/javase/6/docs/api/java/io/IOException.html http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Jun 20, 2012 at 9:52 PM, Benedikt Ritter benerit...@googlemail.com wrote: Hi, I'm still working on https://issues.apache.org/jira/browse/SANDBOX-423 and I wanted to test if all the new exception get thrown correctly. For that reason I implemented a new class - ExceptionThrowingTestBean that properties and methods that throw exceptions when they get called. That way I can test if the InvocationTargetException gets wrapped correctly in. I also implemented getters and setters with default, protected and private visibility. I expected to get an IllegalAccessException wrapped in a PropertyNotAccessibleException. Instead I got: java.lang.Exception: Unexpected exception, expectedorg.apache.commons.beanutils2.exception.PropertyNotAccessibleException but wasorg.apache.commons.beanutils2.exception.PropertyNotFoundException at org.junit.internal.runners.statements.ExpectException.evaluate(ExpectException.java:31) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) Caused by: org.apache.commons.beanutils2.exception.PropertyNotFoundException: Property privateProperty not found in type org.apache.commons.beanutils2.testbeans.ExceptionThrowingTestBean at org.apache.commons.beanutils2.DefaultBeanAccessor.get(DefaultBeanAccessor.java:73) at org.apache.commons.beanutils2.GetPropertyTestCase.getPrivateProperty(GetPropertyTestCase.java:93) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.ExpectException.evaluate(ExpectException.java:22) ... 17 more Caused by: java.beans.IntrospectionException: Property 'privateProperty' does not exist in bean of type org.apache.commons.beanutils2
Re: [collections] Cleanup of trunk
Are we going through that Java 5 vs Java 6 discussion again? ;)
Thomas: I always wanted to work on collections but there hasn't been much
activity since I joined the ML. I'd be happy to contribute some patches.
Benedikt
Von meinem iPhone gesendet
Am 24.06.2012 um 14:10 schrieb Gary Gregory garydgreg...@gmail.com:
I am +1 to all your proposed changes.
Gary
On Jun 24, 2012, at 5:29, 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)
this has been discussed for vfs a few weeks ago, and my
understanding was that this proposal was well received, so what do
you think about doing the same for collections?
- unit tests: there are currently two unit tests for certain classes
that are almost similar, e.g. TestListOrderedMap and
TestListOrderedMap2. Does anybody know why this exists?
also I would like to go to annotation based unit tests like in the
other components and rename the tests to the common style:
ClassNameTest.
- consistency with commons rules. There are several things that are
different to other components atm:
o authors contained in source files
o no changes.xml to track changes
o since and version tags are a bit different
o package.html should be package-info.java
and I guess other things too that I have not spotted yet.
Are there any objections / suggestions to continue with the cleanup?
Thomas
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [BeanUtils2] In what cases can we expect to see an IllegalAccessException?
Hey Simo, thanks for the feedback. I hope that you could make your deadline ;-) I'll implement that ASAP. Just one comment: 2012/6/25 Simone Tripodi simonetrip...@apache.org: Hi Bene, [SNIP] that is fine, but just throw the expected exception, no needs to throw an IllegalAccessException first. To keep code symmetry that would mean to change other sections of the code that throw checked exceptions as well (DefaultBeanProperties for example). Do you agree? thanks, Benedikt looking forward your patch, TIA! -Simo [1] http://docs.oracle.com/javase/6/docs/api/java/lang/reflect/InvocationTargetException.html#getTargetException() http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.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: r1356439 - /commons/proper/commons-site/trunk/src/site/xdoc/sandbox/index.xml
I'm happy to see this commit ;-) I hope this will get us some more contributers. 2012/7/2 simonetrip...@apache.org: Author: simonetripodi Date: Mon Jul 2 19:53:03 2012 New Revision: 1356439 URL: http://svn.apache.org/viewvc?rev=1356439view=rev Log: added beanutils2 in the sandbox list Modified: commons/proper/commons-site/trunk/src/site/xdoc/sandbox/index.xml Modified: commons/proper/commons-site/trunk/src/site/xdoc/sandbox/index.xml URL: http://svn.apache.org/viewvc/commons/proper/commons-site/trunk/src/site/xdoc/sandbox/index.xml?rev=1356439r1=1356438r2=1356439view=diff == --- commons/proper/commons-site/trunk/src/site/xdoc/sandbox/index.xml (original) +++ commons/proper/commons-site/trunk/src/site/xdoc/sandbox/index.xml Mon Jul 2 19:53:03 2012 @@ -33,6 +33,8 @@ table !-- This list should agree with ../../site.xml -- trthSandbox/thth/th/tr +trtda href=beanutils2/BeanUtils2/a/td +tdRedesign of Commons BeanUtils./td/tr trtda href=cli2/CLI2/a/td tdRedesign of Commons CLI./td/tr trtda href=convert/Convert/a/td - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Does this break binary compatibility?
Hi Sebastien, have a look at: http://wiki.eclipse.org/Evolving_Java-based_APIs http://wiki.eclipse.org/Evolving_Java-based_APIs_2 http://wiki.eclipse.org/Evolving_Java-based_APIs_3 In section Evolving API classes - API methods and constructors it says: Change result type (including void) - Breaks compatibility Can anyone verify that? Regards, Benedikt 2012/7/9 Sébastien Brisard sebastien.bris...@m4x.org: All, in Commons-Math, class RealVector has a method unitize() which divides each component of this by the norm. The vector is changed in place. The current signature of this method is public void unitize() Most methods in class RealVector implement a fluent API. I would like unitize() to follow the same paradigm. In other words, I would like to change the signature to public RealVector unitize() this method now returning this. Question is: does this break binary compatibility? Although clirr reports an error, I fail to see how this change can cause any problem. Thanks in advance for your advice, Sébastien - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons-DbUtils 1.5 based on RC1
Hi Simo, 2012/7/16 Simone Tripodi simonetrip...@apache.org: Impressive feedbacks Gary, thanks a lot! -1 with mvn clear site for https://repository.apache.org/content/repositories/orgapachecommons-054/commons-dbutils/commons-dbutils/1.5/commons-dbutils-1.5-src.zip : [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.0:site (default-site) on project commons-dbutils: Error during page generation: Erro r rendering Maven report: Could not find resource 'C:\temp\commons-dbutils-1.5-src/pmd-ruleset.xml'. - [Help 1] My setup: Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500) Maven home: C:\Java\apache-maven-3.0.4\bin\.. Java version: 1.6.0_31, vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\jdk1.6.0_31\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows has to be fixed - no doubts :) Minor: PMD says: Avoid unused private methods. do you have any hint on how to have them fixed? I mean (IIUC) these methods are for an internal use only... what am I missing? TIA! :) Not great: Coverage for DbUtils is 12%: http://people.apache.org/builds/commons/dbutils/1.5/RC1/site/cobertura/org.apache.commons.dbutils.DbUtils.html not so nice indeed, but if they are a non-blocking issue I would go ahead with a RC2... unless someone else is stepping up for quickly provide patches/checks in tests in a short while. I'm working on a patch for this (always wanted to try out Mocktio), but I'll not be able to finish it till tomorrow evening. If the patch doesn't make it into dbutil 1.5 we'll have the coverage for 1.6 ;-) Benedikt Thanks a lot, have a nice day! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.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: [VOTE] Release Apache Commons-DbUtils 1.5 based on RC1
Have a look at https://issues.apache.org/jira/browse/DBUTILS-94 ;) Bene 2012/7/17 Simone Tripodi simonetrip...@apache.org: If the patch doesn't make it into dbutil 1.5 we'll have the coverage for 1.6 ;-) release early and often is a mantra that we should apply more... often :) -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.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
[functor] Downloads page broken?
Hi, does anybody else experience problems with the download page of functor? http://commons.apache.org/functor/download_functor.cgi gives me 403 Forbidden. Regards, Benedikt - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [functor] Downloads page broken?
Hey Simo, Sorry if I'm getting something wrong, but http://commons.apache.org/functor/ says that functor 1.0 has been released in October 2011. If this information is wrong the text should be changed to something like there have not been no releases yet. Although this might raise the question why a component in proper does not provide any releases :-) Benedikt 2012/7/20 Simone Tripodi simonetrip...@apache.org: Since [functor] has never been released, it doesn't worry me - cgi will be regenerated for the release http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Fri, Jul 20, 2012 at 11:35 AM, Liviu Tudor liviu.tu...@gmail.com wrote: I get the same :( Liv Liviu Tudor E: liviu.tu...@gmail.com C: +1 650-2833815 (USA) M: +44 (0)7591540313 (UK, Europe) W: http://about.me/liviutudor Skype: liviutudor I'm nobody, nobody's perfect -- therefore I'm perfect! On 20/07/2012 02:30, Benedikt Ritter benerit...@gmail.com wrote: Hi, does anybody else experience problems with the download page of functor? http://commons.apache.org/functor/download_functor.cgi gives me 403 Forbidden. 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
Re: [chain2] serialVersionUID
Hi Elijah, if you need a introduction to serialization, I recommend to read the corresponding chapters in Effective Java by Josh Blooch [1]. Regards, Benedikt [1] http://www.amazon.com/Effective-Java-Edition-Joshua-Bloch/dp/0321356683/ref=sr_1_1?ie=UTF8qid=1343119885sr=8-1keywords=effective+java 2012/7/24 Jörg Schaible joerg.schai...@scalaris.com: Hi Elijah, Elijah Zupancic wrote: Thanks Jörg! It sounds like we will need to change them all in chain because we have changed the package name. Well, since they are all different objects now, the Java runtime will not try to match them anyway, so it is for this special case not really required. However, if you consider a change, I'd like to propose to use everywhere a constant that reflects the day of change: servialVersionUID = 20120724L; // format MMDD It's easier then to keep track of changes. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[dbcp] Encoding problems on dbcp site?
Hi, I'm having problems with the dbcp website. It displays diamonds with question marks inside for example between Commons and DBCP in the sidebar. Usually that is sign of an encoding problem. Can anyone verify that? thanks, Benedikt - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [dbcp] Encoding problems on dbcp site?
2012/7/25 Jörg Schaible joerg.schai...@scalaris.com: Benedikt Ritter wrote: Hi, I'm having problems with the dbcp website. It displays diamonds with question marks inside for example between Commons and DBCP in the sidebar. Usually that is sign of an encoding problem. Can anyone verify that? I see the same with Konqueror and Firefox. I'm pretty sure that it has something to do with those #xA0; in the site.xml [1] Any idea why we don't nbsp; ? Benedikt [1] http://svn.apache.org/viewvc/commons/proper/dbcp/trunk/src/site/site.xml?view=markup - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [chain2] serialVersionUID
2012/7/26 sebb seb...@gmail.com: On 26 July 2012 18:29, Brent Worden brent.wor...@gmail.com wrote: On Thu, Jul 26, 2012 at 3:48 AM, sebb seb...@gmail.com wrote: On 25 July 2012 07:54, Jörg Schaible joerg.schai...@scalaris.com wrote: sebb wrote: On 24 July 2012 09:11, Jörg Schaible joerg.schai...@scalaris.com wrote: Hi Elijah, Elijah Zupancic wrote: Thanks Jörg! It sounds like we will need to change them all in chain because we have changed the package name. Well, since they are all different objects now, the Java runtime will not try to match them anyway, so it is for this special case not really required. +1 However, if you consider a change, I'd like to propose to use everywhere a constant that reflects the day of change: servialVersionUID = 20120724L; // format MMDD It's easier then to keep track of changes. +0 Ideally the svuid is only changed when necessary. I don't think the id should be updated just because a new method was added, or code was updated. The danger with using the date is that maintainers may update the id whenever the source is updated. I did not say that. I know; but the fact that the id is a date may (mis)lead maintainers into updating it too often. If we do decide to use the day, maybe it should have a comment such as: // MMDD date of last change to serialized form. - Jörg Since the serialized form will never change without a release, the svuid could also be aligned to the component version. Yes, but the same issue applies: it may not be necessary to change the svuid for each new version. This is particularly true of patch releases. I really don't see an issue here. People who have commit access know what they do and their commits get reviewed by the ML. People who don't have commit access will get a double review. First from the person who applies a patch and then from the ML. I like Jörgs approach (and I have adopted it for my work). Benedikt Thanks, Brent - 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: r1365262 - in /commons/proper/chain/trunk: apps/example2/src/main/java/org/apache/commons/chain2/apps/example/ core/src/main/java/org/apache/commons/chain2/ core/src/main/java/org/apac
2012/7/26 sebb seb...@gmail.com:
On 24 July 2012 20:56, eli...@apache.org wrote:
Author: elijah
Date: Tue Jul 24 19:56:21 2012
New Revision: 1365262
URL: http://svn.apache.org/viewvc?rev=1365262view=rev
Log:
CHAIN-75 Updated serialVersionUID field in chain classes to a format based
on the current date
As far as I call tell, this breaks serialisation across versions.
package names have changed, so it is broken anyway.
Modified:
commons/proper/chain/trunk/apps/example2/src/main/java/org/apache/commons/chain2/apps/example/ExampleServlet.java
commons/proper/chain/trunk/core/src/main/java/org/apache/commons/chain2/ChainException.java
commons/proper/chain/trunk/core/src/main/java/org/apache/commons/chain2/generic/DispatchException.java
commons/proper/chain/trunk/core/src/main/java/org/apache/commons/chain2/impl/ContextBase.java
commons/proper/chain/trunk/core/src/main/java/org/apache/commons/chain2/impl/ContextMap.java
commons/proper/chain/trunk/core/src/test/java/org/apache/commons/chain2/generic/DispatchCommandTestCase.java
commons/proper/chain/trunk/core/src/test/java/org/apache/commons/chain2/impl/TestContext.java
commons/proper/chain/trunk/src/changes/changes.xml
commons/proper/chain/trunk/web/src/main/java/org/apache/commons/chain2/web/ChainServlet.java
commons/proper/chain/trunk/web/src/main/java/org/apache/commons/chain2/web/WebContext.java
commons/proper/chain/trunk/web/src/main/java/org/apache/commons/chain2/web/faces/FacesWebContext.java
commons/proper/chain/trunk/web/src/main/java/org/apache/commons/chain2/web/portlet/PortletWebContext.java
commons/proper/chain/trunk/web/src/main/java/org/apache/commons/chain2/web/servlet/ChainProcessor.java
commons/proper/chain/trunk/web/src/main/java/org/apache/commons/chain2/web/servlet/ServletWebContext.java
Modified:
commons/proper/chain/trunk/apps/example2/src/main/java/org/apache/commons/chain2/apps/example/ExampleServlet.java
URL:
http://svn.apache.org/viewvc/commons/proper/chain/trunk/apps/example2/src/main/java/org/apache/commons/chain2/apps/example/ExampleServlet.java?rev=1365262r1=1365261r2=1365262view=diff
==
---
commons/proper/chain/trunk/apps/example2/src/main/java/org/apache/commons/chain2/apps/example/ExampleServlet.java
(original)
+++
commons/proper/chain/trunk/apps/example2/src/main/java/org/apache/commons/chain2/apps/example/ExampleServlet.java
Tue Jul 24 19:56:21 2012
@@ -39,7 +39,7 @@ public class ExampleServlet extends Http
/**
*
*/
-private static final long serialVersionUID = 1L;
+private static final long serialVersionUID = 20120724L;
private String servletName;
Modified:
commons/proper/chain/trunk/core/src/main/java/org/apache/commons/chain2/ChainException.java
URL:
http://svn.apache.org/viewvc/commons/proper/chain/trunk/core/src/main/java/org/apache/commons/chain2/ChainException.java?rev=1365262r1=1365261r2=1365262view=diff
==
---
commons/proper/chain/trunk/core/src/main/java/org/apache/commons/chain2/ChainException.java
(original)
+++
commons/proper/chain/trunk/core/src/main/java/org/apache/commons/chain2/ChainException.java
Tue Jul 24 19:56:21 2012
@@ -30,7 +30,7 @@ public class ChainException extends Runt
/**
*
*/
-private static final long serialVersionUID = 1L;
+private static final long serialVersionUID = 20120724L;
/**
* Context used when exception occurred.
Modified:
commons/proper/chain/trunk/core/src/main/java/org/apache/commons/chain2/generic/DispatchException.java
URL:
http://svn.apache.org/viewvc/commons/proper/chain/trunk/core/src/main/java/org/apache/commons/chain2/generic/DispatchException.java?rev=1365262r1=1365261r2=1365262view=diff
==
---
commons/proper/chain/trunk/core/src/main/java/org/apache/commons/chain2/generic/DispatchException.java
(original)
+++
commons/proper/chain/trunk/core/src/main/java/org/apache/commons/chain2/generic/DispatchException.java
Tue Jul 24 19:56:21 2012
@@ -16,11 +16,11 @@
*/
package org.apache.commons.chain2.generic;
-import java.util.Map;
-
import org.apache.commons.chain2.ChainException;
import org.apache.commons.chain2.Command;
+import java.util.Map;
+
/**
* Runtime Exception that wraps an underlying exception thrown during the
* execution of a {@link org.apache.commons.chain2.Command} or {@link
org.apache.commons.chain2.Chain}.
@@ -32,7 +32,7 @@ public class DispatchException extends C
/**
*
*/
-private static final long serialVersionUID = 1L;
+private static final long serialVersionUID = 20120724L;
public DispatchException(String message) {
Re: [chain2] serialVersionUID
2012/7/26 Bruno P. Kinoshita brunodepau...@yahoo.com.br: From: Benedikt Ritter benerit...@gmail.com To: Commons Developers List dev@commons.apache.org Sent: Thursday, 26 July 2012 3:28 PM Subject: Re: [chain2] serialVersionUID 2012/7/26 sebb seb...@gmail.com: On 26 July 2012 18:29, Brent Worden brent.wor...@gmail.com wrote: On Thu, Jul 26, 2012 at 3:48 AM, sebb seb...@gmail.com wrote: On 25 July 2012 07:54, Jörg Schaible joerg.schai...@scalaris.com wrote: sebb wrote: On 24 July 2012 09:11, Jörg Schaible joerg.schai...@scalaris.com wrote: Hi Elijah, Elijah Zupancic wrote: Thanks Jörg! It sounds like we will need to change them all in chain because we have changed the package name. Well, since they are all different objects now, the Java runtime will not try to match them anyway, so it is for this special case not really required. +1 However, if you consider a change, I'd like to propose to use everywhere a constant that reflects the day of change: servialVersionUID = 20120724L; // format MMDD It's easier then to keep track of changes. +0 Ideally the svuid is only changed when necessary. I don't think the id should be updated just because a new method was added, or code was updated. The danger with using the date is that maintainers may update the id whenever the source is updated. I did not say that. I know; but the fact that the id is a date may (mis)lead maintainers into updating it too often. If we do decide to use the day, maybe it should have a comment such as: // MMDD date of last change to serialized form. - Jörg Since the serialized form will never change without a release, the svuid could also be aligned to the component version. Yes, but the same issue applies: it may not be necessary to change the svuid for each new version. This is particularly true of patch releases. I really don't see an issue here. People who have commit access know what they do and their commits get reviewed by the ML. People who don't have commit access will get a double review. First from the person who applies a patch and then from the ML. I like Jörgs approach (and I have adopted it for my work). Benedikt Hi all, Hi I'm no specialist in Java serialization, but I have one question (that may be stupid so I apologize in advance :-) about using a date as svuid. There are no stupid questions, only stupid answers! ;) Say that someone from Japan (GMT +9) commits a class to [functor] using svuid 20120727 at 00:30 AM. Then some 12 hours later I (based in Brazil, GMT -3) find a bug in his class, modify a field or move the class to some other package. Depends on the case. If you you are changing a field you have to consider if that affects serialization. So you would have to change the svid if objects serialized in an older version can not be serialized back. If you move the class to another package you have broken any compatibility. So it doesn't really matter. Would be better to change the svid to make this fact explicit. But from a technical point of view it is not needed (correct me, if I'm wrong here) Then I would have to update the svuid, but as in my current timezone the svuid is 20120727 too, I would have to take some action, like waiting until the next day, increase the time precision (+ timezone?) or ask here in the mailing list for help. What would be the correct action in situations like this? On my projects I'm using a layout that with a higher prescision (MMDDHHMM) so that case rarely happens. In the case you described, I would simply set the svid to 20120728. Again I recommend reading the chapters about serialization in effective java. Josh Blooch can explain it a lot better than I can ;) HTH Benedikt And as I'm very lazy, I really like using the Eclipse feature to generate the svuid automagically (I believe it uses JDK serialver tool), but with some practice I could get used to using any other standard adopted by a project too :-) Just my 0.02 cents. Hope that helps. -Bruno Thanks, Brent - 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 Bruno P. Kinoshita http://kinoshita.eti.br http://tupilabs.com - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Proposal Commons-JNDI
2012/8/8 Gary Gregory garydgreg...@gmail.com: On Wed, Aug 8, 2012 at 10:14 AM, Jochen Wiedmann jochen.wiedm...@gmail.comwrote: On Wed, Aug 8, 2012 at 10:29 AM, Jörg Schaible joerg.schai...@scalaris.com wrote: Jochen Wiedmann wrote: Hi, I'd like to propose a new component Commons JNDI for the sandbox. The aim would be to have a very lightweight JNDI implementation (no server, or something like that) that's not necessarily suitable for production, but ideally suited for use in test suites, and the like. For example, commons dbcp might use this to verify configuration via JNDI. The new implementation ought to be driven by property, XML, or JSON files. Possible starting points: - Import Simple JNDI, which already comes very close to the target. Henri Yandell, one of the Simple JNDI authors has given his agreement. - Import Tomcat JNDI, no contact with the Tomcat developers exists on that topic. WDYT? Ever looked at simple-jndi? Now located at http://code.google.com/p/osjava/wiki/SimpleJNDI Ever read the first of my suggested options? Yes, kinda ;) I was thinking in looking in our own backyard first, which may improve ApacheDS *and* give us new code. Note that I did not write new component because I am not 100% convinced yet that this needs to be in a new component. Could it live, for example, in [lang]? Hi, I'd argue that [lang]'s focus is the java.lang package (and some of the stuff in java.util ;-). Most people looking for the stuff that [lang] supports right now don't need a JNDI implementation (I guess...). A new component makes sense for me. Benedikt Gary -- In other words: what could be seen as a socially debilitating failure of character can certainly work to your advantage too. (Linus Torvalds, but the use in the signature tells something about me as well.) - 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 JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK 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
[BeanUtils2] WeakHashMap is not a cache (?)
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
[BeanUtils2] Working on mapped properties
Hi all, I've started work on mapped properties and just want to be sure, that I'm going in the right direction. I've had a look at BU1 and found the MappedPropertyDescirptor class. Now my plan is to adapt that class to BU2 and use it to build up the functionality needed to handle mapped properties. I'll also copy related test classes. After that the DefaultBeanProperties class has to be extended so that it can handle mapped properties. Any comments? Regards, Benedikt - 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 (?)
Hi, 2012/8/13 Adrian Crum adrian.c...@sandglass-software.com: http://ci.apache.org/projects/ofbiz/site/javadocs/org/ofbiz/base/util/cache/package-summary.html thanks for the input! As far as I understand the LRUMap seems to be more appropriate than a map using some sort of reference. But I'll have a look anyway! The LRUMap from commons is not thread safe so we will have to deal with that. Benedikt -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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [site] yet another proposal on how to restyle the commons site
2012/8/30 Gary Gregory garydgreg...@gmail.com: On Thu, Aug 30, 2012 at 10:50 AM, Benedikt Ritter benerit...@gmail.comwrote: Hi Simo, great work, I really like the fluido skin and would like to see it go live for commons. One minor issue: does the releases section need to have a drop down although there is only one entry in the sub menu? IMHO the commons parent site does not need a releases section at all. The list displayed is the same as the one from the components sub section. OTOH it would be cool if the releases page displayed the last recently released components sorted by date with a link to their release notes. But I guess that would imply a lot of maintenance work. Unless there is a way to pick up the latest posts from announce@... That would be even cooler ;-) Gary Regards, Benedikt 2012/8/30 Simone Tripodi simonetrip...@apache.org: Hi all guys, new Apache Maven Fluido Skin is gonna be released soon, I started experimenting locally how the _main_ commons site would look alike if the new skin would be applied (with some modifications): voilà[1] :) If you think that putting more effort on it would worth, I am glad to continue doing more work on applying also to a component site (with different layout), publish to my local ASF space, and see the result - OTOH I'll become definitively silent and won't bother on that topic anymore :) WDYT? Many thanks in advance, all the best! -Simo [1] http://people.apache.org/~simonetripodi/commons/index.html http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.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 JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK 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: [site] yet another proposal on how to restyle the commons site
2012/8/30 Simone Tripodi simonetrip...@apache.org: Hi all! - I find the slider gadget thingy disconcerting. I do not know that it will slide, I thought it was a bug and that the other components were missing (see above). Then, poof!, it does slide. I would not use it so prominently if at all. table restored, more work on the carousel could improve the l'n'f IMHO but let's back to the roots first :) - Does not look good on my iPhone. The main issue is that the top menu bar takes up a third of the screen. We need to consider mobile IMO. Agreed. unfortunately Twitter Bootstrap just provides a responsive design wich adapts the desktop components to mobile phones - and they announced in the ML they don't have any plan (yet?) to write aport on the mobile. Fortunately, I can still provide you a sample with the classic sidebar menu navigation - as shown in[1] - which should adapt better on mobile phones. Can you please verify it? TIA! Hi Simo, I've uploaded a screenshot of that page taken with my mobile [1]. Doesn't look to well, anything you can do about that? Benedikt [1] https://dl.dropbox.com/u/3058827/fluido-commons-on-iPhone.PNG There's no Apache or Apache Commons logo, presumably because these use relative links, and the images are missing. Could you add the directory so we can see what it would look like? done! At that point I'll be working on applying the skin on a component to see how it looks like to show you, hopefully we will find an agreement and definitively upgrade the commons site :P Have a nice day, all the best! -Simo [1] http://people.apache.org/~simonetripodi/commons-sidebar/index.html http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.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: [site] yet another proposal on how to restyle the commons site
Hi again, on my mobile, the top navi does not fit into the horizontal space causing a line break. That will display Components and Sandbox above the header of the side bar. I'll upload a screenshot as soon as I'm at home. Great work, Simo! Benedikt PS: I liked the side scrolling widget from the first version :-) 2012/8/31 Gary Gregory garydgreg...@gmail.com: So much better on the iPhone! Thanks Simo. I agree with Sebb's comments. Well done. Gary On Aug 31, 2012, at 5:09, Simone Tripodi simonetrip...@apache.org wrote: Hi again, Thanks to Christian Grobmeier, we also added the responsive bootstrap css. I re-uploaded the site, can you please have a look at it? TIA, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Fri, Aug 31, 2012 at 8:58 AM, Simone Tripodi simonetrip...@apache.org wrote: I've uploaded a screenshot of that page taken with my mobile [1]. Doesn't look to well, anything you can do about that? :( Step 1: Make Welcome to the Apache Commons half its current font size. yup, I have no more bullets in my gun that the one Gary suggested, I just re-uploaded the site[1] How does it look? TIA, -Simo [1] http://people.apache.org/~simonetripodi/commons-sidebar/ http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.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] FindBugs' Switch statement found in class.method where default case is missing
Hi Gary, IMHO FindBugs is supposed to point you at code fragments that potentially could cause subtle bugs. If say that the code in codec is carefully constructed and everything is backed up by junit tests, I'd say a default clause is nosy and doesn't add anything. OTOH if you can not see that no default clause is required at first sight, I would prefer a default clause in favor of a code comment. Benedikt 2012/9/4 Gary Gregory garydgreg...@gmail.com: Hi All: FindBugs can give warnings like: Switch statement found in org.apache.commons.codec.binary.Base32.decode(byte[], int, int, BaseNCodec$Context) where default case is missing In this case for [codec], it looks like the code was carefully constructed and that no default clause is needed. In these cases for any component, this FindBugs issue feels like a style issue, is it worth changing the code to add a default clause like: default: // ok to fall through for other values. break; Or does this feel like noise to you all? Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK 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: [configuration] Plan for 2.0
Hi Oliver, there are a lot of @author tags. As far as I know, the use of author tags is deprecated in commons, so the mentioned developers and contributors should be moved to pom.xml and changes.xml. Benedikt 2012/9/7 Oliver Heger oliver.he...@oliver-heger.de: Hi all, the pom was updated to make 2.0-SNAPSHOT the current development version. This means we are free to implement major changes without having to enforce binary backwards compatibility. The question is: What are the goals for version 2.0? I would recommend to define a clear focus so that the next release will not take too long. Obviously there are already people waiting for a [configuration] version compatible with [lang3]. Some points I have in mind are the following ones: - Switch to [lang3]. This is the main reason for going to version 2.0 because this cannot be done in a binary compatible way. - Improve thread safety and concurrent implementations in general. - Rework reloading. This is related to the previous point because I think the tight coupling of the current reloading implementation is one of the root causes making the implementation of thread-safe configurations so hard. - Have a look at older Jira tickets which have been postponed because they would break binary compatibility. Any other points, wishes, or opinions? We should discuss the points separately when it comes to their implementation. 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: [math] Is this good practice?
Hi,
2012/9/10 Luc Maisonobe luc.maison...@free.fr:
Le 10/09/2012 21:08, Sébastien Brisard a écrit :
Hi,
Hi Sébastien,
I thought it was not good practice to rely on exception in
unexceptional circumstances. In ArrayFieldVector, there are numerous
occurences of the following pattern
public FieldVectorT add(FieldVectorT v)
throws DimensionMismatchException {
try {
return add((ArrayFieldVectorT) v);
} catch (ClassCastException cce) {
checkVectorDimensions(v);
T[] out = buildArray(data.length);
for (int i = 0; i data.length; i++) {
out[i] = data[i].add(v.getEntry(i));
}
return new ArrayFieldVectorT(field, out, false);
}
}
The catch (ClassCastException cce) seems uggly to me. Should I file
a JIRA issue and start replacing with instanceof?
This was done on purpose a long time ago.
At that time, it appeared that it was faster to do it this way, i.e.
attempt by default the fast method which did not rely on getEntry, and
fall back to a loop using getEntry only in the very rare cases the first
fails.
I am not sure this is useful anymore, as JVM optimizers are better and
better (so they may well replace the getEntry on the fly and use direct
array access when they can).
Perhaps you could do some benchmark with a modern JVM and look if this
hack is still useful or not.
If it still is, a comment should be added to make future maintainers
aware of this fact.
Benedikt
best regards,
Luc
Best regards,
Sébastien
-
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: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
2012/9/28 Jörg Schaible joerg.schai...@scalaris.com: Hi Sebb, sebb wrote: On 27 September 2012 23:53, joe...@apache.org wrote: Author: joehni Date: Thu Sep 27 22:53:46 2012 New Revision: 1391258 URL: http://svn.apache.org/viewvc?rev=1391258view=rev Log: Use conversion tables for boolean arrays. I think the previous code was much clearer. At first sight it now looks as though the static arrays are shared (which would not be safe) but in fact they are cloned. At least I should have checked it with a profiler before. Don't we have a YourKit license for Apache somewhere? YourKit has a licence for open source projects. Looks like you only have to contact their sales by mail (using your @apache.org account?!). Benedikt - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1397534 - /commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVPrinter.java
Hi
2012/10/12 ggreg...@apache.org:
Author: ggregory
Date: Fri Oct 12 12:12:44 2012
New Revision: 1397534
URL: http://svn.apache.org/viewvc?rev=1397534view=rev
Log:
Refactor magic strings into constants.
Modified:
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVPrinter.java
Modified:
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVPrinter.java
URL:
http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVPrinter.java?rev=1397534r1=1397533r2=1397534view=diff
==
---
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVPrinter.java
(original)
+++
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVPrinter.java
Fri Oct 12 12:12:44 2012
@@ -25,6 +25,12 @@ import java.io.IOException;
*/
public class CSVPrinter {
+private static final char COMMENT = '#';
How about COMMENT_START ?
Benedikt
+private static final String EMPTY = ;
+private static final char SP = ' ';
+private static final char CR = '\r';
+private static final char LF = '\n';
+
/** The place that the values get written. */
private final Appendable out;
private final CSVFormat format;
@@ -106,19 +112,19 @@ public class CSVPrinter {
println();
}
out.append(format.getCommentStart());
-out.append(' ');
+out.append(SP);
for (int i = 0; i comment.length(); i++) {
final char c = comment.charAt(i);
switch (c) {
-case '\r':
-if (i + 1 comment.length() comment.charAt(i + 1) ==
'\n') {
+case CR:
+if (i + 1 comment.length() comment.charAt(i + 1) == LF)
{
i++;
}
//$FALL-THROUGH$ break intentionally excluded.
-case '\n':
+case LF:
println();
out.append(format.getCommentStart());
-out.append(' ');
+out.append(SP);
break;
default:
out.append(c);
@@ -159,14 +165,14 @@ public class CSVPrinter {
while (pos end) {
char c = value.charAt(pos);
-if (c == '\r' || c == '\n' || c == delim || c == escape) {
+if (c == CR || c == LF || c == delim || c == escape) {
// write out segment up until this char
if (pos start) {
out.append(value, start, pos);
}
-if (c == '\n') {
+if (c == LF) {
c = 'n';
-} else if (c == '\r') {
+} else if (c == CR) {
c = 'r';
}
@@ -212,7 +218,7 @@ public class CSVPrinter {
if (first (c '0' || (c '9' c 'A') || (c 'Z' c
'a') || (c 'z'))) {
quote = true;
// } else if (c == ' ' || c == '\f' || c == '\t') {
-} else if (c = '#') {
+} else if (c = COMMENT) {
// Some other chars at the start of a value caused the
parser to fail, so for now
// encapsulate if we start in anything less than '#'. We are
being conservative
// by including the default comment char too.
@@ -220,7 +226,7 @@ public class CSVPrinter {
} else {
while (pos end) {
c = value.charAt(pos);
-if (c == '\n' || c == '\r' || c == encapsulator || c ==
delim) {
+if (c == LF || c == CR || c == encapsulator || c ==
delim) {
quote = true;
break;
}
@@ -233,7 +239,7 @@ public class CSVPrinter {
// if (c == ' ' || c == '\f' || c == '\t') {
// Some other chars at the end caused the parser to
fail, so for now
// encapsulate if we end in anything less than ' '
-if (c = ' ') {
+if (c = SP) {
quote = true;
}
}
@@ -280,7 +286,7 @@ public class CSVPrinter {
public void print(String value, final boolean checkForEscape) throws
IOException {
if (value == null) {
// null values are considered empty
-value = ;
+value = EMPTY;
}
if (!checkForEscape) {
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1397534 - /commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVPrinter.java
2012/10/12 Gary Gregory garydgreg...@gmail.com:
On Fri, Oct 12, 2012 at 9:56 AM, sebb seb...@gmail.com wrote:
On 12 October 2012 14:50, Gary Gregory garydgreg...@gmail.com wrote:
On Fri, Oct 12, 2012 at 9:39 AM, sebb seb...@gmail.com wrote:
On 12 October 2012 13:38, Gary Gregory garydgreg...@gmail.com wrote:
On Fri, Oct 12, 2012 at 8:22 AM, Benedikt Ritter
benerit...@gmail.com
wrote:
Hi
2012/10/12 ggreg...@apache.org:
Author: ggregory
Date: Fri Oct 12 12:12:44 2012
New Revision: 1397534
URL: http://svn.apache.org/viewvc?rev=1397534view=rev
Log:
Refactor magic strings into constants.
Modified:
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVPrinter.java
Modified:
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVPrinter.java
URL:
http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVPrinter.java?rev=1397534r1=1397533r2=1397534view=diff
==
---
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVPrinter.java
(original)
+++
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVPrinter.java
Fri Oct 12 12:12:44 2012
@@ -25,6 +25,12 @@ import java.io.IOException;
*/
public class CSVPrinter {
+private static final char COMMENT = '#';
How about COMMENT_START ?
I would say yes only /if/ there were a COMMENT_END.
INLINE_COMMENT_INTRODUCER ?
IS_IT_APRIL_1?
No.
But I agree it's not an ideal name.
It's just that COMMENT on its own is not ideal either.
Maybe the solution is to add Javadoc to explain how the # is used to
introduce comments.
Roger that. I added a comment.
G
Or how about COMMENT_MARKER?
I do not know you well enough to read you ;)
G
Gary
Benedikt
+private static final String EMPTY = ;
+private static final char SP = ' ';
+private static final char CR = '\r';
+private static final char LF = '\n';
+
/** The place that the values get written. */
private final Appendable out;
private final CSVFormat format;
@@ -106,19 +112,19 @@ public class CSVPrinter {
println();
}
out.append(format.getCommentStart());
-out.append(' ');
+out.append(SP);
for (int i = 0; i comment.length(); i++) {
final char c = comment.charAt(i);
switch (c) {
-case '\r':
-if (i + 1 comment.length() comment.charAt(i
+ 1)
== '\n') {
+case CR:
+if (i + 1 comment.length() comment.charAt(i
+ 1)
== LF) {
i++;
}
//$FALL-THROUGH$ break intentionally excluded.
-case '\n':
+case LF:
println();
out.append(format.getCommentStart());
-out.append(' ');
+out.append(SP);
break;
default:
out.append(c);
@@ -159,14 +165,14 @@ public class CSVPrinter {
while (pos end) {
char c = value.charAt(pos);
-if (c == '\r' || c == '\n' || c == delim || c ==
escape)
{
+if (c == CR || c == LF || c == delim || c == escape) {
// write out segment up until this char
if (pos start) {
out.append(value, start, pos);
}
-if (c == '\n') {
+if (c == LF) {
c = 'n';
-} else if (c == '\r') {
+} else if (c == CR) {
c = 'r';
}
@@ -212,7 +218,7 @@ public class CSVPrinter {
if (first (c '0' || (c '9' c 'A') || (c
'Z'
c 'a') || (c 'z'))) {
quote = true;
// } else if (c == ' ' || c == '\f' || c == '\t')
{
-} else if (c = '#') {
+} else if (c = COMMENT) {
// Some other chars at the start of a value caused
the
parser to fail, so for now
// encapsulate if we start in anything less than
'#'.
We are being conservative
// by including the default comment char too.
@@ -220,7 +226,7 @@ public class CSVPrinter {
} else {
while (pos end) {
c = value.charAt(pos);
-if (c == '\n' || c == '\r' || c ==
encapsulator
||
c == delim) {
+if (c == LF || c == CR || c == encapsulator
|| c
==
delim
Re: [csv] CSVFormat API names
2012/10/16 Stephen Colebourne scolebou...@joda.org: On 16 October 2012 17:44, Matt Benson gudnabr...@gmail.com wrote: On Tue, Oct 16, 2012 at 11:42 AM, James Carman ja...@carmanconsulting.com wrote: On Tue, Oct 16, 2012 at 12:38 PM, Matt Benson gudnabr...@gmail.com wrote: Are these specific examples not the words you would actually use were you having a discussion on the subject in English? :P Why not just support both? The with* methods would just be aliases for the more natural language method names. I would categorise first in two - mutable builders producing immutable objects - immutable objects Implementing a builder for CSVFormat was discussed a while ago [1]. I think it's the best solution, because the validate method can then made private and no code outside the format has to worry about whether a format is valid or not (right now CSV code calls validate on newly created CSVFormat instances to make sure they are valid.). Anyway there were voices against a builder because it would complicate the API, so we never implemented something like that... Benedikt [1] http://markmail.org/thread/mmeoymd3cpq5jxfr The former should generally have short methods without prefixes, the latter is more complex. For the latter, as a general rule, I use withXxx()/plusXxx()/minusXxx() for items that affect the state and past participle for other methods that manipulate the object in other ways: // affects state (year/month/day) date = date.withYear(2012) date = date.plusYears(6) // aftect multiple pieces of state, so past participle period = period.multipliedBy(6) period = period.negated() This is simply an extension of when you might use setXxx() on a bean, and when you might use a named method. Stephen - 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] CSVFormat API names
2012/10/16 Gary Gregory garydgreg...@gmail.com:
On Tue, Oct 16, 2012 at 1:00 PM, Stephen Colebourne
scolebou...@joda.orgwrote:
On 16 October 2012 17:44, Matt Benson gudnabr...@gmail.com wrote:
On Tue, Oct 16, 2012 at 11:42 AM, James Carman
ja...@carmanconsulting.com wrote:
On Tue, Oct 16, 2012 at 12:38 PM, Matt Benson gudnabr...@gmail.com
wrote:
Are these specific examples not the words you would actually use were
you having a discussion on the subject in English? :P
Why not just support both? The with* methods would just be aliases
for the more natural language method names.
I would categorise first in two
- mutable builders producing immutable objects
- immutable objects
The former should generally have short methods without prefixes, the
latter is more complex.
For the latter, as a general rule, I use
withXxx()/plusXxx()/minusXxx() for items that affect the state and
past participle for other methods that manipulate the object in other
ways:
// affects state (year/month/day)
date = date.withYear(2012)
date = date.plusYears(6)
// aftect multiple pieces of state, so past participle
period = period.multipliedBy(6)
period = period.negated()
This is simply an extension of when you might use setXxx() on a bean,
and when you might use a named method.
I like the idea of two classes: CVSFormat and CVSFormatBuilder but...
My next question is: Does CVSFormat have any public constructors? If not,
the builder can throw exceptions when one of its methods is called and
validation fails. This is nice in the sense that the format object feels
more lightweight and has a simpler/shorter protocol. It also leaves room
for other builders to be added (to configured formats from config files for
example) without growing the format class itself.
If CVSFormat does have public constructors, then the format class still has
to do its own validation. What I gain is the choice of using a kitchen sink
constructor or the fluent builder API, I can choose my style.
If there are two classes, and I cannot build a format without a format
builder, then why not collapse the two classes into one?
Hi Gary,
I agree. I'd favor to have no public constructors and a builder that
is an internal class of CSVFormat. Users create CSVFormatBuilders by
calling a static method on CSVFormat:
CSVFormat format =
CSVFormat.defaults().withDelimiter('#').withCommentStart('/').build();
Where defaults() returns a builder that is initialized with (suprise)
the values of the default format. No need to call a validate method.
Benedikt
Gary
Stephen
-
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
JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0
Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK
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] CSVFormat API names
2012/10/17 sebb seb...@gmail.com:
On 16 October 2012 21:56, Benedikt Ritter benerit...@gmail.com wrote:
2012/10/16 Gary Gregory garydgreg...@gmail.com:
On Tue, Oct 16, 2012 at 1:00 PM, Stephen Colebourne
scolebou...@joda.orgwrote:
On 16 October 2012 17:44, Matt Benson gudnabr...@gmail.com wrote:
On Tue, Oct 16, 2012 at 11:42 AM, James Carman
ja...@carmanconsulting.com wrote:
On Tue, Oct 16, 2012 at 12:38 PM, Matt Benson gudnabr...@gmail.com
wrote:
Are these specific examples not the words you would actually use were
you having a discussion on the subject in English? :P
Why not just support both? The with* methods would just be aliases
for the more natural language method names.
I would categorise first in two
- mutable builders producing immutable objects
- immutable objects
The former should generally have short methods without prefixes, the
latter is more complex.
For the latter, as a general rule, I use
withXxx()/plusXxx()/minusXxx() for items that affect the state and
past participle for other methods that manipulate the object in other
ways:
// affects state (year/month/day)
date = date.withYear(2012)
date = date.plusYears(6)
// aftect multiple pieces of state, so past participle
period = period.multipliedBy(6)
period = period.negated()
This is simply an extension of when you might use setXxx() on a bean,
and when you might use a named method.
I like the idea of two classes: CVSFormat and CVSFormatBuilder but...
My next question is: Does CVSFormat have any public constructors? If not,
the builder can throw exceptions when one of its methods is called and
validation fails. This is nice in the sense that the format object feels
more lightweight and has a simpler/shorter protocol. It also leaves room
for other builders to be added (to configured formats from config files for
example) without growing the format class itself.
If CVSFormat does have public constructors, then the format class still has
to do its own validation. What I gain is the choice of using a kitchen sink
constructor or the fluent builder API, I can choose my style.
If there are two classes, and I cannot build a format without a format
builder, then why not collapse the two classes into one?
Hi Gary,
I agree. I'd favor to have no public constructors and a builder that
is an internal class of CSVFormat. Users create CSVFormatBuilders by
calling a static method on CSVFormat:
CSVFormat format =
CSVFormat.defaults().withDelimiter('#').withCommentStart('/').build();
Where defaults() returns a builder that is initialized with (suprise)
the values of the default format. No need to call a validate method.
If you mean that the build method does the validation, then I agree.
yep, the build should take care of the validation.
I think validation is necessary to check that the defined
meta-characters are distinct.
We could ignore validation and let the user define
escape=delimiter=quote , but I suspect that would generate a lot of
unnecessary user queries when things then go wrong in odd ways.
Benedikt
Gary
Stephen
-
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
JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0
Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK
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
-
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
[BeanUtils2] Caching in BU2
Hi, implementing benchmarks for BU2 has shown, that the WeakHashMap with WeakReferences to the values is not sufficient for caching [1]. The solution I suggested for that issue is not to use WeakReferences as values. This will prevent NPEs if the GC kicks in. But it only resolves part of the problem. WeakHashMap itself does not seem to be the best choice for caching. The problem is, that it uses WeakReferences for it's keys. So the GC will clean up entries, if no strong reference to a key can be found. This certainly isn't what we want. Someone has suggested to use a LRUMap implementation like the one in o.a.collections [2]. How do you feel about that? If we what to use the LRUMap implementation of collections, how would we do that? We con't want to depend on other components, so do we have to copy the code to the BU2 code base? Regards, Benedikt PS: this all applies to BeanUtils1 as well, because we adopted the caching from there. [1] https://issues.apache.org/jira/browse/SANDBOX-433 [2] http://svn.apache.org/viewvc/commons/proper/collections/trunk/src/main/java/org/apache/commons/collections/map/LRUMap.java?view=markup
Re: [OGNL] A new release
Use the mvn site goal. Benedikt Von meinem iPhone gesendet Am 28.10.2012 um 11:24 schrieb Lukasz Lenart lukaszlen...@apache.org: How to generate reports locally ? Thanks in advance -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ - 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: [v2] org.apache.logging.log4j.core.Logger.log(Marker, String, Level, Message, Throwable)
Hey Gary,
wrong ML? ;-)
Regards,
Benedikt
Von meinem iPhone gesendet
Am 04.11.2012 um 15:06 schrieb Gary Gregory garydgreg...@gmail.com:
I wonder if in:
org.apache.logging.log4j.core.Logger.log(Marker, String, Level, Message,
Throwable)
@Override
public void log(Marker marker, String fqcn, Level level, Message data,
Throwable t) {
if (data == null) {
data = new SimpleMessage();
}
config.config.getConfigurationMonitor().checkConfiguration();
config.loggerConfig.log(getName(), marker, fqcn, level, data, t);
}
The null guard should be pushed all the way down to:
org.apache.logging.log4j.core.impl.Log4jLogEvent.Log4jLogEvent(String,
Marker, String, Level, Message, Throwable, MapString, String,
ContextStack, String, StackTraceElement, long)
Which already does some constructor checks for other args.
?
Gary
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0
Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK
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: r1405889 - in /commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration: Configuration.java ImmutableConfiguration.java
Hi Oliver,
2012/11/5 ohe...@apache.org
Author: oheger
Date: Mon Nov 5 17:29:01 2012
New Revision: 1405889
URL: http://svn.apache.org/viewvc?rev=1405889view=rev
Log:
Initial version of an immutable configuration interface.
Added:
commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/ImmutableConfiguration.java
(with props)
Modified:
commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/Configuration.java
Modified:
commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/Configuration.java
URL:
http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/Configuration.java?rev=1405889r1=1405888r2=1405889view=diff
==
---
commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/Configuration.java
(original)
+++
commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/Configuration.java
Mon Nov 5 17:29:01 2012
@@ -17,11 +17,6 @@
package org.apache.commons.configuration;
-import java.math.BigDecimal;
-import java.math.BigInteger;
-import java.util.Iterator;
-import java.util.List;
-import java.util.Properties;
/**
* pThe main Configuration interface./p
@@ -54,7 +49,7 @@ import java.util.Properties;
* @author Commons Configuration team
* @version $Id$
*/
-public interface Configuration
+public interface Configuration extends ImmutableConfiguration
A Configuration IS_A ImmutableConfiguration sounds rather akward. The
JavaDoc of ImmutableConfiguration says The main interface for accessing
configuration data in a read-only fashion. Maybe ImmutableConfiguration
should be renamed to ReadOnlyConfiguration?
Regards,
Benedikt
{
/**
* Return a decorator Configuration containing every key from the
current
@@ -90,24 +85,6 @@ public interface Configuration
Configuration subset(String prefix);
/**
- * Check if the configuration is empty.
- *
- * @return {@code true} if the configuration contains no property,
- * {@code false} otherwise.
- */
-boolean isEmpty();
-
-/**
- * Check if the configuration contains the specified key.
- *
- * @param key the key whose presence in this configuration is to be
tested
- *
- * @return {@code true} if the configuration contains a value for this
- * key, {@code false} otherwise
- */
-boolean containsKey(String key);
-
-/**
* Add a property to the configuration. If it already exists then the
value
* stated here will be added to the configuration entry. For example,
if
* the property:
@@ -147,452 +124,4 @@ public interface Configuration
* Remove all properties from the configuration.
*/
void clear();
-
-/**
- * Gets a property from the configuration. This is the most basic get
- * method for retrieving values of properties. In a typical
implementation
- * of the {@code Configuration} interface the other get methods (that
- * return specific data types) will internally make use of this
method. On
- * this level variable substitution is not yet performed. The returned
- * object is an internal representation of the property value for the
passed
- * in key. It is owned by the {@code Configuration} object. So a
caller
- * should not modify this object. It cannot be guaranteed that this
object
- * will stay constant over time (i.e. further update operations on the
- * configuration may change its internal state).
- *
- * @param key property to retrieve
- * @return the value to which this configuration maps the specified
key, or
- * null if the configuration contains no mapping for this key.
- */
-Object getProperty(String key);
-
-/**
- * Get the list of the keys contained in the configuration that match
the
- * specified prefix. For instance, if the configuration contains the
- * following keys:br
- * {@code db.user, db.pwd, db.url, window.xpos, window.ypos},br
- * an invocation of {@code getKeys(db);}br
- * will return the keys below:br
- * {@code db.user, db.pwd, db.url}.br
- * Note that the prefix itself is included in the result set if there
is a
- * matching key. The exact behavior - how the prefix is actually
- * interpreted - depends on a concrete implementation.
- *
- * @param prefix The prefix to test against.
- * @return An Iterator of keys that match the prefix.
- * @see #getKeys()
- */
-IteratorString getKeys(String prefix);
-
-/**
- * Get the list of the keys contained in the configuration. The
returned
- * iterator can be used to obtain all defined keys. Note that the
exact
- * behavior
Re: svn commit: r1405889 - in /commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration: Configuration.java ImmutableConfiguration.java
2012/11/5 Benedikt Ritter benerit...@gmail.com
Hi Oliver,
2012/11/5 ohe...@apache.org
Author: oheger
Date: Mon Nov 5 17:29:01 2012
New Revision: 1405889
URL: http://svn.apache.org/viewvc?rev=1405889view=rev
Log:
Initial version of an immutable configuration interface.
Added:
commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/ImmutableConfiguration.java
(with props)
Modified:
commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/Configuration.java
Modified:
commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/Configuration.java
URL:
http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/Configuration.java?rev=1405889r1=1405888r2=1405889view=diff
==
---
commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/Configuration.java
(original)
+++
commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/Configuration.java
Mon Nov 5 17:29:01 2012
@@ -17,11 +17,6 @@
package org.apache.commons.configuration;
-import java.math.BigDecimal;
-import java.math.BigInteger;
-import java.util.Iterator;
-import java.util.List;
-import java.util.Properties;
/**
* pThe main Configuration interface./p
@@ -54,7 +49,7 @@ import java.util.Properties;
* @author Commons Configuration team
* @version $Id$
*/
-public interface Configuration
+public interface Configuration extends ImmutableConfiguration
A Configuration IS_A ImmutableConfiguration sounds rather akward. The
JavaDoc of ImmutableConfiguration says The main interface for accessing
configuration data in a read-only fashion. Maybe ImmutableConfiguration
should be renamed to ReadOnlyConfiguration?
Regards,
Benedikt
Looking at the code base, there is no class that implements
ImmutableConfiguration directly and Configuration is the only interface
that extends ImmutableConfiguration. So maybe the two can be merged
together?
Benedikt
{
/**
* Return a decorator Configuration containing every key from the
current
@@ -90,24 +85,6 @@ public interface Configuration
Configuration subset(String prefix);
/**
- * Check if the configuration is empty.
- *
- * @return {@code true} if the configuration contains no property,
- * {@code false} otherwise.
- */
-boolean isEmpty();
-
-/**
- * Check if the configuration contains the specified key.
- *
- * @param key the key whose presence in this configuration is to be
tested
- *
- * @return {@code true} if the configuration contains a value for
this
- * key, {@code false} otherwise
- */
-boolean containsKey(String key);
-
-/**
* Add a property to the configuration. If it already exists then
the value
* stated here will be added to the configuration entry. For
example, if
* the property:
@@ -147,452 +124,4 @@ public interface Configuration
* Remove all properties from the configuration.
*/
void clear();
-
-/**
- * Gets a property from the configuration. This is the most basic get
- * method for retrieving values of properties. In a typical
implementation
- * of the {@code Configuration} interface the other get methods (that
- * return specific data types) will internally make use of this
method. On
- * this level variable substitution is not yet performed. The
returned
- * object is an internal representation of the property value for
the passed
- * in key. It is owned by the {@code Configuration} object. So a
caller
- * should not modify this object. It cannot be guaranteed that this
object
- * will stay constant over time (i.e. further update operations on
the
- * configuration may change its internal state).
- *
- * @param key property to retrieve
- * @return the value to which this configuration maps the specified
key, or
- * null if the configuration contains no mapping for this
key.
- */
-Object getProperty(String key);
-
-/**
- * Get the list of the keys contained in the configuration that
match the
- * specified prefix. For instance, if the configuration contains the
- * following keys:br
- * {@code db.user, db.pwd, db.url, window.xpos, window.ypos},br
- * an invocation of {@code getKeys(db);}br
- * will return the keys below:br
- * {@code db.user, db.pwd, db.url}.br
- * Note that the prefix itself is included in the result set if
there is a
- * matching key. The exact behavior - how the prefix is actually
- * interpreted - depends on a concrete implementation.
- *
- * @param prefix The prefix to test against.
- * @return An Iterator of keys that match
Re: svn commit: r1405889 - in /commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration: Configuration.java ImmutableConfiguration.java
Hi Jörg, specialization between two concpets in the oo paradigm has the semantics of a is-a-relationship. So if Configuration extends ImmutableConfiguration that means (at least for me) that a Configuration is a ImmutableConfiguration. That's what I meant with my first comment. About merging the two: If there is no class that implements ImmutableConfiguration and no interface other then Configuration that extends it. What is the point of having it in the first place? For example the two could be merged together and a class AbstractImmutableConfiguration could implement the merged Interface (let's call it Configuration). That class would throw UnsupportedOperationException if one of the write methods is called. This would be like the definition of Collection.add(E o). Subclasses may implement the add operation but can also chose not to. Benedikt 2012/11/5 Jörg Schaible joerg.schai...@gmx.de Benedikt Ritter wrote: 2012/11/5 Benedikt Ritter benerit...@gmail.com Hi Oliver, 2012/11/5 ohe...@apache.org Author: oheger Date: Mon Nov 5 17:29:01 2012 New Revision: 1405889 URL: http://svn.apache.org/viewvc?rev=1405889view=rev Log: Initial version of an immutable configuration interface. Added: commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/ImmutableConfiguration.java (with props) Modified: commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/Configuration.java Modified: commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/Configuration.java URL: http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/Configuration.java?rev=1405889r1=1405888r2=1405889view=diff == --- commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/Configuration.java (original) +++ commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/Configuration.java Mon Nov 5 17:29:01 2012 @@ -17,11 +17,6 @@ package org.apache.commons.configuration; -import java.math.BigDecimal; -import java.math.BigInteger; -import java.util.Iterator; -import java.util.List; -import java.util.Properties; /** * pThe main Configuration interface./p @@ -54,7 +49,7 @@ import java.util.Properties; * @author Commons Configuration team * @version $Id$ */ -public interface Configuration +public interface Configuration extends ImmutableConfiguration A Configuration IS_A ImmutableConfiguration sounds rather akward. The JavaDoc of ImmutableConfiguration says The main interface for accessing configuration data in a read-only fashion. Maybe ImmutableConfiguration should be renamed to ReadOnlyConfiguration? Regards, Benedikt Looking at the code base, there is no class that implements ImmutableConfiguration directly and Configuration is the only interface that extends ImmutableConfiguration. So maybe the two can be merged together? And why do YOU think, that an immutable and a mutable Configuration is the same thing? Sorry, your comments do not make any sense to me! - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1405889 - in /commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration: Configuration.java ImmutableConfiguration.java
Hi Oliver,
thanks for the clarification. I see where you are going with the design.
What do you think of my proposal to implement the configuration interfaces
like the java collections framework? I can think of
Configurations.unmodifiableConfiguration(Configuration config).
Benedikt
2012/11/6 Oliver Heger oliver.he...@oliver-heger.de
Hi Benedikt,
Am 05.11.2012 21:04, schrieb Benedikt Ritter:
2012/11/5 Benedikt Ritter benerit...@gmail.com
Hi Oliver,
2012/11/5 ohe...@apache.org
Author: oheger
Date: Mon Nov 5 17:29:01 2012
New Revision: 1405889
URL:
http://svn.apache.org/viewvc?**rev=1405889view=revhttp://svn.apache.org/viewvc?rev=1405889view=rev
Log:
Initial version of an immutable configuration interface.
Added:
commons/proper/configuration/**trunk/src/main/java/org/**
apache/commons/configuration/**ImmutableConfiguration.java
(with props)
Modified:
commons/proper/configuration/**trunk/src/main/java/org/**
apache/commons/configuration/**Configuration.java
Modified:
commons/proper/configuration/**trunk/src/main/java/org/**
apache/commons/configuration/**Configuration.java
URL:
http://svn.apache.org/viewvc/**commons/proper/configuration/**
trunk/src/main/java/org/**apache/commons/configuration/**
Configuration.java?rev=**1405889r1=1405888r2=1405889**view=diffhttp://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/Configuration.java?rev=1405889r1=1405888r2=1405889view=diff
==**==**
==
---
commons/proper/configuration/**trunk/src/main/java/org/**
apache/commons/configuration/**Configuration.java
(original)
+++
commons/proper/configuration/**trunk/src/main/java/org/**
apache/commons/configuration/**Configuration.java
Mon Nov 5 17:29:01 2012
@@ -17,11 +17,6 @@
package org.apache.commons.**configuration;
-import java.math.BigDecimal;
-import java.math.BigInteger;
-import java.util.Iterator;
-import java.util.List;
-import java.util.Properties;
/**
* pThe main Configuration interface./p
@@ -54,7 +49,7 @@ import java.util.Properties;
* @author Commons Configuration team
* @version $Id$
*/
-public interface Configuration
+public interface Configuration extends ImmutableConfiguration
A Configuration IS_A ImmutableConfiguration sounds rather akward. The
JavaDoc of ImmutableConfiguration says The main interface for accessing
configuration data in a read-only fashion. Maybe ImmutableConfiguration
should be renamed to ReadOnlyConfiguration?
Regards,
Benedikt
Looking at the code base, there is no class that implements
ImmutableConfiguration directly and Configuration is the only interface
that extends ImmutableConfiguration. So maybe the two can be merged
together?
The ImmutableConfiguration interface has just been extracted from
Configuration in order to implement the feature of immutable
configurations. It contains all methods that do not manipulate the
configuration. A full-blown configuration extends this functionality by
additional update operations.
It is true that currently all concrete Configuration implementations
support the extended interface with update operations. However,
ImmutableConfiguration is implemented by dynamic proxies which provide an
immutable view on an arbitrary Configuration object.
Regarding the name: I am open for suggestions. ReadOnlyConfiguration,
ImmutableConfiguration, UnmodifiableConfiguration,... Maybe a native
speaker can comment?
Oliver
Benedikt
{
/**
* Return a decorator Configuration containing every key from the
current
@@ -90,24 +85,6 @@ public interface Configuration
Configuration subset(String prefix);
/**
- * Check if the configuration is empty.
- *
- * @return {@code true} if the configuration contains no property,
- * {@code false} otherwise.
- */
-boolean isEmpty();
-
-/**
- * Check if the configuration contains the specified key.
- *
- * @param key the key whose presence in this configuration is to be
tested
- *
- * @return {@code true} if the configuration contains a value for
this
- * key, {@code false} otherwise
- */
-boolean containsKey(String key);
-
-/**
* Add a property to the configuration. If it already exists then
the value
* stated here will be added to the configuration entry. For
example, if
* the property:
@@ -147,452 +124,4 @@ public interface Configuration
* Remove all properties from the configuration.
*/
void clear();
-
-/**
- * Gets a property from the configuration. This is the most basic
get
- * method for retrieving values of properties. In a typical
implementation
- * of the {@code Configuration} interface the other get methods
(that
- * return specific data types) will internally
Re: svn commit: r1405889 - in /commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration: Configuration.java ImmutableConfiguration.java
2012/11/6 Oliver Heger oliver.he...@oliver-heger.de
Am 06.11.2012 09:57, schrieb Benedikt Ritter:
Hi Oliver,
thanks for the clarification. I see where you are going with the design.
What do you think of my proposal to implement the configuration interfaces
like the java collections framework? I can think of
Configurations.**unmodifiableConfiguration(**Configuration config).
Such a method already exists in ConfigurationUtils, however it is based on
the dynamic proxy approach. This has the advantage that you only have a
stripped-down interface in hand which does not allow you to call an
unsupported method.
Hi Oliver,
okay, now I get why Configuration has to extend ImmutableConfiguration.
thanks!
Benedikt
Oliver
Benedikt
2012/11/6 Oliver Heger oliver.he...@oliver-heger.de
Hi Benedikt,
Am 05.11.2012 21:04, schrieb Benedikt Ritter:
2012/11/5 Benedikt Ritter benerit...@gmail.com
Hi Oliver,
2012/11/5 ohe...@apache.org
Author: oheger
Date: Mon Nov 5 17:29:01 2012
New Revision: 1405889
URL:
http://svn.apache.org/viewvc?rev=1405889view=revhttp://svn.apache.org/viewvc?**rev=1405889view=rev
http://**svn.apache.org/viewvc?rev=**1405889view=revhttp://svn.apache.org/viewvc?rev=1405889view=rev
Log:
Initial version of an immutable configuration interface.
Added:
commons/proper/configuration/trunk/src/main/java/org/**
apache/commons/configuration/ImmutableConfiguration.java
(with props)
Modified:
commons/proper/configuration/trunk/src/main/java/org/**
apache/commons/configuration/Configuration.java
Modified:
commons/proper/configuration/trunk/src/main/java/org/**
apache/commons/configuration/Configuration.java
URL:
http://svn.apache.org/viewvc/commons/proper/configuration/http://svn.apache.org/viewvc/**commons/proper/configuration/**
trunk/src/main/java/org/apache/commons/configuration/
Configuration.java?rev=1405889r1=1405888r2=1405889**
**view=diffhttp://svn.apache.**org/viewvc/commons/proper/**
configuration/trunk/src/main/**java/org/apache/commons/**
configuration/Configuration.**java?rev=1405889r1=1405888**
r2=1405889view=diffhttp://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/Configuration.java?rev=1405889r1=1405888r2=1405889view=diff
==**==**
==
---
commons/proper/configuration/trunk/src/main/java/org/**
apache/commons/configuration/Configuration.java
(original)
+++
commons/proper/configuration/trunk/src/main/java/org/**
apache/commons/configuration/Configuration.java
Mon Nov 5 17:29:01 2012
@@ -17,11 +17,6 @@
package org.apache.commons.configuration;
-import java.math.BigDecimal;
-import java.math.BigInteger;
-import java.util.Iterator;
-import java.util.List;
-import java.util.Properties;
/**
* pThe main Configuration interface./p
@@ -54,7 +49,7 @@ import java.util.Properties;
* @author Commons Configuration team
* @version $Id$
*/
-public interface Configuration
+public interface Configuration extends ImmutableConfiguration
A Configuration IS_A ImmutableConfiguration sounds rather akward. The
JavaDoc of ImmutableConfiguration says The main interface for
accessing
configuration data in a read-only fashion. Maybe
ImmutableConfiguration
should be renamed to ReadOnlyConfiguration?
Regards,
Benedikt
Looking at the code base, there is no class that implements
ImmutableConfiguration directly and Configuration is the only interface
that extends ImmutableConfiguration. So maybe the two can be merged
together?
The ImmutableConfiguration interface has just been extracted from
Configuration in order to implement the feature of immutable
configurations. It contains all methods that do not manipulate the
configuration. A full-blown configuration extends this functionality by
additional update operations.
It is true that currently all concrete Configuration implementations
support the extended interface with update operations. However,
ImmutableConfiguration is implemented by dynamic proxies which provide an
immutable view on an arbitrary Configuration object.
Regarding the name: I am open for suggestions. ReadOnlyConfiguration,
ImmutableConfiguration, UnmodifiableConfiguration,... Maybe a native
speaker can comment?
Oliver
Benedikt
{
/**
* Return a decorator Configuration containing every key from
the
current
@@ -90,24 +85,6 @@ public interface Configuration
Configuration subset(String prefix);
/**
- * Check if the configuration is empty.
- *
- * @return {@code true} if the configuration contains no
property,
- * {@code false} otherwise.
- */
-boolean isEmpty();
-
-/**
- * Check if the configuration contains the specified key
Re: [LANG] FastDateParserTest is failing
Hi Lam, thanks for your info. Can you file an issue in jira [1] and attach a patch for that? Reagrds, Benedikt [1] https://issues.apache.org/jira/ 2012/11/9 Lam nguyen phuc ruado1...@gmail.com Hi, I cloned the commons-lang repository from github and encountered a failed test in FastDateParserTest. Here is the output from junit: Testcase: testParses took 0.015 sec FAILED ja_JP 1940 G/y/M/d/h/a/E/Z America/New_York expected:Sat Feb 10 12:20:00 SGT 1940 but was:Sat Feb 10 12:00:00 SGT 1940 junit.framework.AssertionFailedError: ja_JP 1940 G/y/M/d/h/a/E/Z America/New_York expected:Sat Feb 10 12:20:00 SGT 1940 but was:Sat Feb 10 12:00:00 SGT 1940 at org.apache.commons.lang3.time.FastDateParserTest.testParses(FastDateParserTest.java:221) Digging into the test code, I found out that the format patterns (long and short forms) did not take minute into account, thus causing the test to fail in some certain locale (in this case it is the Japanese locale). Changing the patterns as follows effectively fixes the failing test: private static final String SHORT_FORMAT_NOERA = y/M/d/h/a/m/E/Z; private static final String LONG_FORMAT_NOERA = ///////; Regards, Harry
Re: svn commit: r1410759 - in /commons/proper/csv/trunk/src: main/java/org/apache/commons/csv/CSVFormat.java test/java/org/apache/commons/csv/CSVFormatBuilderTest.java test/java/org/apache/commons/csv
2012/11/17 ggreg...@apache.org
Author: ggregory
Date: Sat Nov 17 18:00:38 2012
New Revision: 1410759
URL: http://svn.apache.org/viewvc?rev=1410759view=rev
Log:
[CSV-68] Use the Builder pattern for CSVFormat.
Modified:
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVFormatBuilderTest.java
commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVFormatTest.java
Modified:
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
URL:
http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java?rev=1410759r1=1410758r2=1410759view=diff
==
---
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
(original)
+++
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
Sat Nov 17 18:00:38 2012
@@ -29,12 +29,13 @@ import java.io.IOException;
import java.io.Reader;
import java.io.Serializable;
import java.io.StringWriter;
+import java.util.Arrays;
/**
* The format specification of a CSV file.
*
* This class is immutable.
- *
+ *
* @version $Id$
*/
public class CSVFormat implements Serializable {
@@ -125,8 +126,8 @@ public class CSVFormat implements Serial
/**
* Creates a new CSV format builds.
- *
- * @param delimiter
+ *
+ * @param delimiter
*the char used for value separation, must not be a line
break character
* @throws IllegalArgumentException if the delimiter is a line break
character
*/
@@ -137,7 +138,7 @@ public class CSVFormat implements Serial
public static CSVFormatBuilder newBuilder(final CSVFormat format) {
return new CSVFormatBuilder(format);
}
-
+
/**
* Standard comma separated format, as for {@link #RFC4180} but
allowing blank lines.
* ul
@@ -158,7 +159,7 @@ public class CSVFormat implements Serial
*the char used for value separation, must not be a line
break character
* @param quoteChar
*the char used as value encapsulation marker
- * @param quotePolicy
+ * @param quotePolicy
*the quote policy
* @param commentStart
*the char used for comment identification
@@ -174,10 +175,12 @@ public class CSVFormat implements Serial
*the header
* @throws IllegalArgumentException if the delimiter is a line break
character
*/
-private CSVFormat(final char delimiter, final Character quoteChar,
final Quote quotePolicy, final Character commentStart, final Character
escape, final
-boolean ignoreSurroundingSpaces, final boolean
ignoreEmptyLines, final String lineSeparator,
-final String[] header) {
-if (isLineBreak(delimiter)) {
+private CSVFormat(final char delimiter, final Character quoteChar,
final Quote quotePolicy, final Character commentStart, final Character
escape, final
+boolean ignoreSurroundingSpaces, final boolean
ignoreEmptyLines, final String lineSeparator,
+ final String[] header)
+{
+if (isLineBreak(delimiter))
+{
throw new IllegalArgumentException(The delimiter cannot be a
line break);
}
this.delimiter = delimiter;
@@ -188,7 +191,7 @@ public class CSVFormat implements Serial
this.ignoreSurroundingSpaces = ignoreSurroundingSpaces;
this.ignoreEmptyLines = ignoreEmptyLines;
this.recordSeparator = lineSeparator;
-this.header = header;
+this.header = header == null ? null : header.clone();
Well, that looks a lot simpler :) Thanks Gary!
What else has to be done to finish CSV-68?
Regards,
Benedikt
}
/**
@@ -373,7 +376,109 @@ public class CSVFormat implements Serial
public Quote getQuotePolicy() {
return quotePolicy;
}
-
+
+@Override
+public int hashCode()
+{
+final int prime = 31;
+int result = 1;
+
+result = prime * result + delimiter;
+result = prime * result + ((quotePolicy == null) ? 0 :
quotePolicy.hashCode());
+result = prime * result + ((quoteChar == null) ? 0 :
quoteChar.hashCode());
+result = prime * result + ((commentStart == null) ? 0 :
commentStart.hashCode());
+result = prime * result + ((escape == null) ? 0 :
escape.hashCode());
+result = prime * result + (ignoreSurroundingSpaces ? 1231 : 1237);
+result = prime * result + (ignoreEmptyLines ? 1231 : 1237);
+result = prime * result + ((recordSeparator == null) ? 0 :
recordSeparator.hashCode());
+result = prime * result + Arrays.hashCode(header);
+return result;
+}
+
+@Override
+public boolean
[CSV] Discussion about the new CSVFormatBuilder
Hi,
Gary and I did some work on CSV-68 Use the Builder Pattern to create
CSVFormats [1].
We have implemented a builder for CSVFormats in trunk. It is capable of...
...creating a CSVFormat from scratch by only passing in a delimiter:
CSVFormat format = CSVFormat.newBuilder(',').build();
...creating a CSVFormat from the commons-csv defaults (RFC4180 but ignoring
empty lines)
CSVFormat format = CSVFormat.defaults().build();
...creating a CSVFormat based on a
CSVFormat copyOfRFC4180 = CSVFormat.newBuilder(CSVFormat.RFC4180).build();
The builders provides the same fluent API like CSVFormat did before by
returning itself:
CSVFormat format =
CSVFormat.newBuilder(',').withRecordSeparator('\n').withIgnoreEmptyLines(true).build();
Using a builder has several advantages:
- the construction of CSVFormats can be separated from the CSVFormat itself
- the interface of CSVFormat is now much smaller
- if we want to add another parameter to CSVFormat we only have to change
CSVFormat's private ctor, and the build method. We had to change every
withXXX method before.
- CSVFormats can only be created into a valid state, because the builder
internally uses the validate method, which was package visible before and
therefore not accessible to users.
However there are also disadvantages:
- the builder is more verbose; it forces users to the build() method, where
every withXXX method returned a CSVFormat before.
- it has been argued that using the builder pattern only to make sure
CSVFormats are valid is overengineered. No other library has this kind of
validation.
Please share your thoughts about the builder.
Regards,
Benedikt
[1] https://issues.apache.org/jira/browse/CSV-68
Re: [CSV] Discussion about the new CSVFormatBuilder
Hey Ted, no I was referring to the comments of CSV-68, where it was stated that no other CSV library provides validation of the used CSV formats (and hence it can be removed from commons csv entirely). Benedikt 2012/11/20 Ted Dunning ted.dunn...@gmail.com Surely you meant to say no other commons library. Builder patterns are relatively common. See guava for instance: http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/base/Splitter.html On Tue, Nov 20, 2012 at 11:49 AM, Gary Gregory garydgreg...@gmail.com wrote: - it has been argued that using the builder pattern only to make sure CSVFormats are valid is overengineered. No other library has this kind of validation.
Re: svn commit: r1411919 - /commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
2012/11/21 Gary Gregory garydgreg...@gmail.com
On Tue, Nov 20, 2012 at 6:22 PM, s...@apache.org wrote:
Author: sebb
Date: Tue Nov 20 23:22:21 2012
New Revision: 1411919
URL: http://svn.apache.org/viewvc?rev=1411919view=rev
Log:
Make some methods package-protected to avoid the need for synthetic
accessors.
TODO consider whether to do so for the fields as well
How about just using getters and keeping encapsulation cleaner?
I agree.
Gary
Modified:
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
Modified:
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
URL:
http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java?rev=1411919r1=1411918r2=1411919view=diff
==
---
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
(original)
+++
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
Tue Nov 20 23:22:21 2012
@@ -175,9 +175,9 @@ public class CSVFormat implements Serial
*the header
* @throws IllegalArgumentException if the delimiter is a line break
character
*/
-private CSVFormat(final char delimiter, final Character quoteChar,
final Quote quotePolicy, final Character commentStart, final Character
escape, final
-boolean ignoreSurroundingSpaces, final boolean
ignoreEmptyLines, final String lineSeparator,
- final String[] header)
+// package protected to give access without needing a synthetic
accessor
+CSVFormat(final char delimiter, final Character quoteChar, final
Quote quotePolicy, final Character commentStart, final Character escape,
+ final boolean ignoreSurroundingSpaces, final boolean
ignoreEmptyLines, final String lineSeparator, final String[] header)
{
if (isLineBreak(delimiter))
{
@@ -202,7 +202,8 @@ public class CSVFormat implements Serial
*
* @return true if codec/code is a line break character
*/
-private static boolean isLineBreak(final Character c) {
+// package protected to give access without needing a synthetic
accessor
+static boolean isLineBreak(final Character c) {
return c != null isLineBreak(c.charValue());
}
I still don't know where this methods belong to. They are defined in
CSVFormat and used in the builder and in CSVFormat ctor. I think the call
to isLineBreak could be moved to build() to get rid of that redundancy.
OTH if we need the method in other classes, maybe it makes sense to define
a package private util class, say CSVCharacters or CSVSymbols.
Benedikt
@@ -214,7 +215,8 @@ public class CSVFormat implements Serial
*
* @return true if codec/code is a line break character
*/
-private static boolean isLineBreak(final char c) {
+// package protected to give access without needing a synthetic
accessor
+static boolean isLineBreak(final char c) {
return c == LF || c == CR;
}
@@ -539,7 +541,9 @@ public class CSVFormat implements Serial
* @param format
*The format to use values from
*/
-private CSVFormatBuilder(CSVFormat format) {
+@SuppressWarnings(synthetic-access) // TODO fields could be
made package-protected
+// package protected to give access without needing a synthetic
accessor
+CSVFormatBuilder(CSVFormat format) {
this(format.delimiter, format.quoteChar, format.quotePolicy,
format.commentStart, format.escape,
format.ignoreSurroundingSpaces,
format.ignoreEmptyLines,
@@ -553,7 +557,8 @@ public class CSVFormat implements Serial
*the char used for value separation, must not be a
line break character
* @throws IllegalArgumentException if the delimiter is a line
break character
*/
-private CSVFormatBuilder(final char delimiter){
+// package protected to give access without needing a synthetic
accessor
+CSVFormatBuilder(final char delimiter){
this(delimiter, null, null, null, null, false, false, null,
null);
}
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0
Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [CSV] Discussion about the new CSVFormatBuilder
Maybe we first have to decide if we want validation of CSVFormats at construction time or not. If not, the changes of CSV-68 can be reverted. Benedikt 2012/11/21 James Carman ja...@carmanconsulting.com I don't really have a problem with the extra call to build() before you have something useful. It does give us the ability to do validation on the object before you build it. If we choose not to do the validation at this time, that's fine, but if we ever do choose to add that in the future, we don't have to break API backward compatibility to do so. On Tue, Nov 20, 2012 at 5:57 PM, Gary Gregory garydgreg...@gmail.com wrote: Ok this is good. Let's see some healthy debating. :) What is the alternate API? To me the bother is the extra build() call, but that's the pattern. Could an alt API be used and co-exist? Is making the ctor an option? It would have to do some validation. Gary On Nov 20, 2012, at 16:59, Emmanuel Bourg ebo...@apache.org wrote: Le 20/11/2012 20:01, Benedikt Ritter a écrit : Please share your thoughts about the builder. Sorry Benedikt but I have to say I really don't like this design. I prefer a simpler API for the reasons you mentioned in the disadvantages. The minor improvements from the developer's point of view are much less important than the ease of use from user's point of view. 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: [beanutils] Property access on a fluent API
Hi Oliver,
AFAIK beanutils is not restricted to pure JavaBeans. The project website
just says that the component provides simple wrappers around the java
refelct and introspect API. So I would say, that the functionality you
propsed would fit nicely into BU (maybe the scope has changed and now the
name is a bit misleading?!).
Regarding your question where to implement it: I did some work on beanutils
2, but there are several outstanding issues on JIRA that block me from
providing more patches. So development is a bit stuck until someone can
step in and review those issues and the patches attached to them.
After that, there are a some points to address before BU2 can be promoted
to proper and eventually be released [1].
So if you need that functionality quickly, it would probably be easier to
add it to BU1 and push out a release.
Regards,
Benedikt
[1] http://markmail.org/thread/5zgoyid5ld7otwsv
2012/12/5 Oliver Heger oliver.he...@oliver-heger.de
Hi all,
in [configuration] [beanutils] is used to initialize properties of Java
objects defined in configuration files. This works fine as long as the
objects conform to the Java Beans specification.
Now I would like to initialize other objects, too, which implement a
fluent interface as follows:
class Param {
public Param setFoo(String value) {
...
}
}
Such properties are not detected by [beanutils] with its standard
mechanism. As a work-around, I currently provide specific BeanInfo classes
for the affected Java objects I want to process. They use a mechanism which
scans a class's methods and adds property descriptors for set methods even
if they have a non-void return type.
Because fluent APIs like that are becoming more and more popular I wonder
whether it would be a good extension for [beanutils] to be more flexible
when searching for property access methods. I guess, ultimately, I am
asking for an extension point where a custom introspection mechanism can be
plugged in so that client code is free to provide additional property
descriptors for its data objects.
Would there be interest to add such a feature to [beanutils]? For version
1.x or 2.0?
Oliver
--**--**-
To unsubscribe, e-mail:
dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [beanutils] Property access on a fluent API
2012/12/6 Oliver Heger oliver.he...@oliver-heger.de
Am 05.12.2012 23:13, schrieb Benedikt Ritter:
Hi Oliver,
AFAIK beanutils is not restricted to pure JavaBeans. The project website
just says that the component provides simple wrappers around the java
refelct and introspect API. So I would say, that the functionality you
propsed would fit nicely into BU (maybe the scope has changed and now the
name is a bit misleading?!).
Regarding your question where to implement it: I did some work on
beanutils
2, but there are several outstanding issues on JIRA that block me from
providing more patches. So development is a bit stuck until someone can
step in and review those issues and the patches attached to them.
After that, there are a some points to address before BU2 can be promoted
to proper and eventually be released [1].
So if you need that functionality quickly, it would probably be easier to
add it to BU1 and push out a release.
Thanks,
it is not that urgent because [configuration] is currently undergoing a
redesign for the 2.0 version which will take some time. I hope to find some
cycles in the near future to provide a patch with the proposed feature for
[beanutils].
Okay, I guess that I'll be able to adapt your patch for [beanutils2].
Unfortunately, there does not seem to be much interest in this component
currently.
Sadly that's true :-)
Benedikt
Oliver
Regards,
Benedikt
[1]
http://markmail.org/thread/**5zgoyid5ld7otwsvhttp://markmail.org/thread/5zgoyid5ld7otwsv
2012/12/5 Oliver Heger oliver.he...@oliver-heger.de
Hi all,
in [configuration] [beanutils] is used to initialize properties of Java
objects defined in configuration files. This works fine as long as the
objects conform to the Java Beans specification.
Now I would like to initialize other objects, too, which implement a
fluent interface as follows:
class Param {
public Param setFoo(String value) {
...
}
}
Such properties are not detected by [beanutils] with its standard
mechanism. As a work-around, I currently provide specific BeanInfo
classes
for the affected Java objects I want to process. They use a mechanism
which
scans a class's methods and adds property descriptors for set methods
even
if they have a non-void return type.
Because fluent APIs like that are becoming more and more popular I wonder
whether it would be a good extension for [beanutils] to be more flexible
when searching for property access methods. I guess, ultimately, I am
asking for an extension point where a custom introspection mechanism can
be
plugged in so that client code is free to provide additional property
descriptors for its data objects.
Would there be interest to add such a feature to [beanutils]? For version
1.x or 2.0?
Oliver
--**
--**-
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
Re: [Math] Request for future releases: kill Cobertura
What about a sonar instance for commons? Benedikt
Re: [Math] Request for future releases: kill Cobertura
2012/12/20 luc l...@spaceroots.org Le 2012-12-20 15:01, Phil Steitz a écrit : On 12/19/12 6:19 PM, Gilles Sadowski wrote: Hello. Hi all, The situation with Cobertura is fairly annoying, perhaps particularly so for Commons Math because of the size of the code base (and thus the fairly large number of unit tests). As it just happened, a few minor problems have now delayed the release by several days because I have to wait about 4 hours for the site generation to complete (on a _fast_ machine). Hence the request to remove Cobertura from the site target, or at least from the site:stage-deploy step, so that a new vote can take place as soon as a problem is fixed. [I would even argue that it is not that useful to include Cobertura in the release process because the amount of code coverage is not acted upon (i.e. low coverage would not block a release IIUC).] Do you agree? +1 If so, can we change that for Commons Math only, or should this be done at the parent level? Is is just a matter of adding cobertura.skiptrue/**cobertura.skip in a new profile? This is an argument that we have from time to time. IMO the parent should contain a minimal set of plugins and component POMs should explicitly include the ones they want. I would be +1 for dropping Coberta from the parent pom. I will play devils advocate. Cobertura is really useful and provides useful information. It also clearly help popularizing [math] as we can prove it is a well tested component. So I don't agree removing it totally. However, I agree it has become really annoying mainly due to its very poor performances with respect to Bobyqa tests. It really takes hours to perform all site generation. Gilles spoke about 4 hours on a fast machine, but my home computer is not fast and it takes much longer to me. When I want to do a full generation, I let it run overnight. So if another mean to have the same information is available (or to make cobertura run faster, especially for the bobyqa test), then I would be glad to drop cobertura. If there are no other means, I would not be glad. I would prefer than the output from the test coverage would end up in the public site. Even if only the current trunk is covered, that would be sufficient for my needs, so if some existing continuous integration system can be set up, I'm fine with that. Note that we really need to get information down to line of code level, as it is the only way we can extend tests. The cobertura report is really nice for that as it directly provides colored versions of the source code which are really easy to use for the developer. Hi Luc, have a look at the test installation Oliver has set up: https://analysis.apache.org/components/index/121254, for example have a look at the org.apache.commons.lang3.builder package: https://analysis.apache.org/components/index/121815 If you click on one of the magnifying glasses on the right side, you get a detailed view of a particular class. Click on the Coverage tab in the top right side and you will have the coverage displayed like in Cobertura. Benedikt best regards, Luc Phil Regards, Gilles --**--** - 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-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: autosuggest
Hi Karnakar, if you want to contribute to one of the commons sub projects, the best way is to create an issue in JIRA [1] and attach a SVN patch file to it. People will generally not download files send to the ML. thanks! Benedikt [1] https://issues.apache.org/jira 2013/1/1 karnakar thallapalli karnaka...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] Cleanup of trunk
2013/1/15 Thomas Neidhart thomas.neidh...@gmail.com On 01/15/2013 07:17 PM, Dennis Lundberg wrote: On 2013-01-12 15:03, Thomas Neidhart wrote: Hi, Hi Thomas A while back I made changes to the Maven build so that it produces the same output as the Ant build. The should mean that we can get rid of the old Ant build if we want to. I think the ant build script it is used by gump atm. One thing that I'd like to do is to restructure the source code into several separate Maven modules, so that there is a specific module for commons-logging-api. The current setup is error prone, as it is extracting certain files from certain archives and then repackaging them again, with the risk of loosing meta data like MANIFEST.MF. Yes I like that idea, the current packaging and testing is quite odd, e.g. one has to run mvn integration-test to do the actual unit tests. btw. does anybody know how to automatically do a verify phase when doing a mvn site, otherwise the results of the integration-tests are not published. I would like to do a similar cleanup as for email also for logging and aim for a 1.2 release in the coming weeks. The things I have in mind: * update to Java 5 I'm -1 on this change. I don't see any reason to do it. We don't need features from a more recent Java version in commons-logging. As others have said: most users of commons-logging are old and older apps. In general I am fine with keeping the current JDK compatibility, but there are also a few points in favor of such a change: * how can we ensure compatibility with such outdated JDKs today? minimum jdk I have installed is JDK 1.5 * the codebase is at parts quite complex as it has to deal with such a wide range of supported JDKs. Reducing the number for (future) releases would simplify the maintenance (and we could remove some old code for pre-1.4 JDKs). There are still lots of other (non-legacy) projects that use commons-logging, e.g. spring. But maybe we could also keep the 1.x branch on java 1.1, and create a 2.x branch which targets java 5. Maybe we can ask Spring folks, what they would like to see in a new release, like we did for Tomcat? * comply to default maven structure +1 already did so. * update to Junit 4 +1 still open. * fix the open issues wrt thread safety Sebb created some issues about this topic, and there is one (reproducible) deadlock scenario with the WeakHashtable. Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
