Re: [GUMP] Build Failure - commons-latka
Stefan Bodewig [EMAIL PROTECTED] wrote on 19/10/2002 12:50:30 AM: On Fri, 18 Oct 2002, Morgan Delagrange [EMAIL PROTECTED] wrote: It's too bad that Jelly + deps isn't GUMPified yet. GUMP is a very valuable process for keeping everybody's API on the same page. At one point it was, but I simply couldn't keep up with the rate new dependencies were added. If I could get help from the Jelly developers, I'd be happy to start a new effort. Here to help, what can I do? -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [GUMP] Build Failure - commons-latka
Stefan Bodewig [EMAIL PROTECTED] wrote on 19/10/2002 12:00:59 AM: On 18 Oct 2002, Ted Husted [EMAIL PROTECTED] wrote: cannot resolve symbol : class Jelly Houston we have a problem, Jelly is currently not Gumpified (because it depends on a lot of stuff that is not Gumpified either and even seemed to run into circular dependencies). Is there a stable binary of Jelly that Latka could depend upon? Note If it's a URL, how about http://www.ibiblio.org/maven/commons-jelly/jars/commons-jelly-SNAPSHOT.jar as that always holds the last published version of jelly? that Latka would lose the there is an incompatible API change warning mechanism of Gump if we allowed it to have binary dependencies. -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [GUMP] Build Failure - commons-latka
Stefan Bodewig [EMAIL PROTECTED] wrote on 19/10/2002 02:06:49 AM: On Fri, 18 Oct 2002, Morgan Delagrange [EMAIL PROTECTED] wrote: Well I'd be happy to help out, Cool, I've just committed a new version, but it won't build (don't know how to build grant, werkz or cyberneko). This just means that Grant I could help with... I can re-gen the ant build file that's there. What else do you need to know? The dependencies are pretty obvious: junit and ant. It's not that much and for commons-grant I guess it would be trivial to add a vanilla Ant build file so it could be Gumpified. I didn't search for cyberneko, it may be buildable from source. Grant had a build file there before, but I've regenerated it, and tested. The jar target works ok. Werkz I could probably help with. -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: cvs commit: jakarta-commons/latka project.xml
Morgan, the snapshot should be the latest version. If not, let me know and I'll fix it -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers [EMAIL PROTECTED] wrote on 19/10/2002 05:40:10 AM: morgand 2002/10/18 12:40:10 Modified:latkaproject.xml Log: more up-to-date version of HttpClient (last snapshot appears to have bug wrt. retrieving HEAD requests) Revision ChangesPath 1.34 +1 -1 jakarta-commons/latka/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/latka/project.xml,v retrieving revision 1.33 retrieving revision 1.34 diff -u -r1.33 -r1.34 --- project.xml 15 Oct 2002 19:04:18 - 1.33 +++ project.xml 18 Oct 2002 19:40:10 - 1.34 @@ -99,7 +99,7 @@ dependency idcommons-httpclient/id - versionSNAPSHOT/version + version2.0alpha1-20020829/version urlhttp://jakarta.apache.org/commons/httpclient//url /dependency -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
[collections] bug in CollectionUtils.cardinality method
There is a bug in cardinality method, which shows, when obj parameter is
null;
It leads to NullPointerException.
In order to reveal it, add line
assertEquals(0, CollectionUtils.cardinality(null, _b));
to testCardinality in TestCollectionUtils.
One variant of correct implementation is following:
public static int cardinality(Object obj, final Collection col) {
int count = 0;
Iterator it = col.iterator();
if(null==obj){
while(it.hasNext()){
Object elt = it.next();
if(null==elt){
count++;
}
}
}else{
while(it.hasNext()) {
Object elt = it.next();
if(obj.equals(elt)) {
count++;
}
}
}
return count;
}
Kind regards.
Sergey Yevtushenko
--
To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
[collections] suggestion for change in MultiHasMap
Current implementation of MultiHashMap has one problem with notion of
equality.
Namely, when for some key some value is added, and then removed from
MultiMap, and this value was only one value, that was put for this key
than multimap wouldn't be equal to with same values of key/value pairs,
in which this new value was not added.
This can be demonstrated by following test (can be added to
TestMultiHashMap.testMapEquals):
public void testMapEquals() {
MultiHashMap one = new MultiHashMap();
Integer value = new Integer(1);
one.put(One, value);
one.remove(One, value);
MultiHashMap two = new MultiHashMap();
assertEquals(two, one);
}
Suggested fix for this problem is the following change in code of
MultiHashMap.remove(Object key, Object value).
public Object remove( Object key, Object item )
{
ArrayList valuesForKey = (ArrayList) super.get( key );
if ( valuesForKey == null )
return null;
valuesForKey.remove( item );
//start of change
if(valuesForKey.isEmpty()){
remove(key);
}
//end of change
return item;
}
Best Regards.
Sergey Yevtushenko
--
To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [beanutils] ready for 1.5 release?
hi steve interesting and useful comments. improved caching is something that i want to look at once this release is out of the way, so i think that probably the best thing to do would be to go without testing (of this fix) for this release. if you'll hang around, maybe we can all try to work out some good strategies for cache testing and maybe open out this topic to other components which are likely to have similar needs (eg. collections, lang, reflection). - robert On Friday, October 18, 2002, at 11:33 PM, Steve Downey wrote: If an API can't be tested, I tend to think there is something wrong with it. I've occasionally resorted to using protected deprecated methods to create a 'Testable' version of a class. Our practice is to have the tests in a different package than the classes being tested, so package scope doesn't help. Another tack, for aspects like cacheing, which really need to be invisible, is to add instrumentation. Either some way of quering cache stats, or registering a callback or event handler for cache misses. In practice, I like to be able to monitor the performance of a cache. The cache strategy might need to be changed, or the cache dumped entirely, if the cache just adds overhead. The application shouldn't care about caching, but the management of the app might. On Friday 18 October 2002 03:01 pm, Craig R. McClanahan wrote: On Fri, 18 Oct 2002, robert burrell donkin wrote: Date: Fri, 18 Oct 2002 19:47:07 +0100 From: robert burrell donkin [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Subject: Re: [beanutils] ready for 1.5 release? the patch looks ok. since it's a fix for a caching bug and all the caching code is private to the class, it's going to be very hard to create a test case without changing some of the variables from private to package (say). This is an area that I've often wondered about -- how do most people deal with writing unit tests for this sort of stuff? In principle, I think it'd be OK to make things package instead of private, if we also seal the JAR file (i.e. add a Sealed: attribute in the manifest) to prevent application classes from declaring themselves into the org.apache.commons.beanutils package and therefore gaining access to these variables. it shouldn't be too hard to create a test case but the question is whether it's worth altering the API to do so. if the general feeling is that a test case for this issue is worth making this change, i'll take a look at writing one now. - robert Craig On Friday, October 18, 2002, at 07:29 PM, Scott Sanders wrote: With the exception of 12728/12458. I have not yet looked at creating a test case for it, but I do believe the patch is solid. I have attached it if you get a chance to look at it. Other than that, I think we are ready. Scott -Original Message- From: robert burrell donkin [mailto:robertburrelldonkin;blueyonder.co.uk] Sent: Friday, October 18, 2002 11:24 AM To: Jakarta Commons Developers List Subject: [beanutils] ready for 1.5 release? are we ready for a beanutils 1.5 release? - robert -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache. org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache. org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache. org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache. org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [jelly] build and distribution issues (was Re: [Latka][Proposal] MakeJelly a required dependency?)
James Strachan [EMAIL PROTECTED] wrote on 18/10/2002 05:49:49 PM: [snip] Agreed. I think there are 2 issues that need to be resolved. Dependency tracking == We need a way of knowing, for sure, what are the dependencies on the small 'core' of Jelly. Then as other libraries are used, knowing what are the added dependencies if any. So I'm assuming that from the Maven build process perspective, the core would be one project then each library a seperate sub project with its own additional dependencies - all of which can then be easily documented. John Casey did mail me some stuff to help do this but unfortunately I've not had chance to get to it yet. +1 but it depends on the decision on jars below [snip] additional jars. Ant's core + optional jar is a fairly simple split and works OK I think. Though as an end user having just one big ant.jar would make life easier (having to deperately download ant-optional.jar has always irritated me a little, I'd rather that just be distributed in the core distro). Another alternative is we could have 1 jar for the core then 1 jar per additional library. I guess this is technically the proper thing to do - though it could lead to gazillions of jars - already there are 22 libraries; most of which are pretty small with just a few small, simple classes, so having a different jar per library seems a little over the top. So I guess the choices are mostly A) one big jar B) one core jar with useful stuff (say the libraries core, bean, util) then an optional.jar for everything else C) as above but maybe a couple of other extra jars for different libraries. Like a jelly-swing.jar for just JellySwing D) one jar for core then 1 jar per library Given that the current xerces jar is 1.6Mb, having a single Jelly jar of around 400-500k doesn't seem so bad. I guess splitting some of the bigger optional libraries off (like JellySwing) might help keep the size down a bit. What are others thoughts on this? Are big jars a problem these days? Ultimately, what would totally rock would be if Jelly could use a Maven/JJAR mechanism that each Jelly library could be downloaded as its required along with any dependent jars required kinda like how Maven plugins work. Though thats a significant bit of work :-) I'd appreciate any thoughts folks have on these issues. I'm leaning to A for now and maybe B or C over time. DittoI never did like the ant split, and the number of questions it causes. It *has* to be made very clear in the documentation what 'optional' means if we go that way. -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13780] New: - Option.hasArgName() has a bug
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13780.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13780
Option.hasArgName() has a bug
Summary: Option.hasArgName() has a bug
Product: Commons
Version: 1.0 Beta 2
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: CLI
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I noticed a bug.
NullPointerException is occured, with helpFormatter.printHelp()
This is a patch.
--- Option.java.orig2002-10-18 18:27:53.0 +0900
+++ Option.java 2002-10-19 16:48:35.0 +0900
@@ -395,7 +395,7 @@
* set.
*/
public boolean hasArgName() {
- return (this.argName != null || this.argName.length() 0 );
+ return (this.argName != null this.argName.length() 0 );
}
/**
Or just
return (this.argName != null);
??
--
To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [lang][patch] StringUtils
Fredrik Westermarck wrote: Hi! I have attached a patch that improves the javadoc in StringUtils. Please review the patch and commit it if it meet the standards. -- Fredrik Westermarck -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [collections] bug in CollectionUtils.cardinality method
We're in the release process so this cannot be fixed at the moment, so
please file a bug in Bugzilla so we don't lose track of this:
http://issues.apache.org/bugzilla/enter_bug.cgi?product=Commons
regards,
michael
Sergey Yevtushenko wrote:
There is a bug in cardinality method, which shows, when obj parameter is
null;
It leads to NullPointerException.
In order to reveal it, add line
assertEquals(0, CollectionUtils.cardinality(null, _b));
to testCardinality in TestCollectionUtils.
One variant of correct implementation is following:
public static int cardinality(Object obj, final Collection col) {
int count = 0;
Iterator it = col.iterator();
if(null==obj){
while(it.hasNext()){
Object elt = it.next();
if(null==elt){
count++;
}
}
}else{
while(it.hasNext()) {
Object elt = it.next();
if(obj.equals(elt)) {
count++;
}
}
}
return count;
}
Kind regards.
Sergey Yevtushenko
--
To unsubscribe, e-mail:
mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:commons-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [collections] suggestion for change in MultiHasMap
We're in the release process so this cannot be fixed at the moment, so
please file a bug in Bugzilla so we don't lose track of this:
http://issues.apache.org/bugzilla/enter_bug.cgi?product=Commons
regards,
michael
Sergey Yevtushenko wrote:
Current implementation of MultiHashMap has one problem with notion of
equality.
Namely, when for some key some value is added, and then removed from
MultiMap, and this value was only one value, that was put for this key
than multimap wouldn't be equal to with same values of key/value pairs,
in which this new value was not added.
This can be demonstrated by following test (can be added to
TestMultiHashMap.testMapEquals):
public void testMapEquals() {
MultiHashMap one = new MultiHashMap();
Integer value = new Integer(1);
one.put(One, value);
one.remove(One, value);
MultiHashMap two = new MultiHashMap();
assertEquals(two, one);
}
Suggested fix for this problem is the following change in code of
MultiHashMap.remove(Object key, Object value).
public Object remove( Object key, Object item )
{
ArrayList valuesForKey = (ArrayList) super.get( key );
if ( valuesForKey == null )
return null;
valuesForKey.remove( item );
//start of change
if(valuesForKey.isEmpty()){
remove(key);
}
//end of change
return item;
}
Best Regards.
Sergey Yevtushenko
--
To unsubscribe, e-mail:
mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:commons-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: JavaDoc of org.apache.commons.lang.builder.EqualsBuilder
On Friday 18 October 2002 07:06 pm, Stephen Colebourne wrote: [Alex, I have replied to commons-dev mailing list as the most appropriate place for the discussion] Inline... - Original Message - From: Alex Blewitt [EMAIL PROTECTED] I've just read the JavaDoc for EqualsBuilder V 1.0 on the Apahce website, and have a few comments which I think you may like to take into account: o You shouldn't use 'instanceof' in the test for equality of type. You should instead use this.getClass() == other.getClass(). The simple reason for this is the equals method is meant to be reflexive (i.e. a.equals(b) == b.equals(a)) and using 'instanceof' it is possible to break that contract. For example, classes A and B (extends A), then a.equals(b) will return true (even if there are attributes of 'b' that are added or different) and b.equals(a) will never be true, even if there are no attributes of 'b' added. Note that this also works for superclass equality; it is safe to use 'super.equals(other)' if there are other tests that need to be done. Note that the rules, laid out by Joshua Bloch, are generally regarded as false since it breaks the assumptions of the equality method and have widely been ridiculed. [However, note that you need to test for 'other==null' since null instanceof X always returns false.] I think I agree about the instanceof check in the code. It probably should be class equality. I am unclear as to what you find exactly wrong with Josh Bloch's book. I have never heard of it being ridiculed, but then maybe I'm not in the right circles :-) Ridicule is probably a bit strong. But what does turn out to be the case is that inheritance and equals don't mix. Even if you fix the reflexive problem, by slicing, that will break transitivity. super1 = sub1, super1 = sub2, but sub1 != sub2. Here's the best discussion on the subject I could find: http://www.cuj.com/java/articles/a19.htm?topic=java It's an article by Angelika Langer and Klaus Kreft, reviewing the state of the art in equals(). One thing that they uncover is that if the base class uses instanceof, so should the sub class. And, the practice in the standard library is to use instanceof. o You also comment that any field used in equality testing must be used in hashcode, and vice versa. The reverse is not true. You can have a hashCode method that returns a constant '0' (thereby not using any of the fields) with an implementation of equals that works for any (or all) fields. Correct, the javadoc is probably over harsh. Although it's probably good practice. A bad hash code really messes up a hashtable. Instead of the O(1) you were expecting, you end up with O(n), since it collapses to an expensive list. o You don't point out that static and non-transient fields should not be used in the implementation of equals, which is required as per the spec. I assume you mean transient. I reckon they don't harm if they are checked (static final and transient, static would harm). Static shouldn't harm either. It just shouldn't be necessary. o You don't give an example of how to integrate with a superclass. In general, for classes that have an implementation of an equals method in a (non-Object) superclass, you should also have a first line test 'super.equals(other)' as well. The best thing to point out is that value-type heirarchies are to be avoided. They have deep conceptual problems. Like the problems with equals. Composition, rather than inheritance, seems to be the right thing to do. However, if you are stuck with it, then knowing what you are getting yourself into is probably a good idea. -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [sql] Refactor JDBCTransformTast?
From: [EMAIL PROTECTED] Fantastic.. I started breaking it up, but I would love to see what else you have. I'll put my effort on hold until Monday then.. Also, what is the recommeded database to write testcode against? Axion? Go for it. Axion is already used in the unit tests. James --- http://radio.weblogs.com/0112098/ __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [beanutils] ready for 1.5 release?
On Saturday 19 October 2002 04:40 am, robert burrell donkin wrote: hi steve interesting and useful comments. improved caching is something that i want to look at once this release is out of the way, so i think that probably the best thing to do would be to go without testing (of this fix) for this release. If the other tests pass, then it's at least correct to the first order. And the patch appears to be correct. if you'll hang around, maybe we can all try to work out some good strategies for cache testing and maybe open out this topic to other components which are likely to have similar needs (eg. collections, lang, reflection). I'm not planning on going anywhere. - robert On Friday, October 18, 2002, at 11:33 PM, Steve Downey wrote: If an API can't be tested, I tend to think there is something wrong with it. I've occasionally resorted to using protected deprecated methods to create a 'Testable' version of a class. Our practice is to have the tests in a different package than the classes being tested, so package scope doesn't help. Another tack, for aspects like cacheing, which really need to be invisible, is to add instrumentation. Either some way of quering cache stats, or registering a callback or event handler for cache misses. In practice, I like to be able to monitor the performance of a cache. The cache strategy might need to be changed, or the cache dumped entirely, if the cache just adds overhead. The application shouldn't care about caching, but the management of the app might. On Friday 18 October 2002 03:01 pm, Craig R. McClanahan wrote: On Fri, 18 Oct 2002, robert burrell donkin wrote: Date: Fri, 18 Oct 2002 19:47:07 +0100 From: robert burrell donkin [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Subject: Re: [beanutils] ready for 1.5 release? the patch looks ok. since it's a fix for a caching bug and all the caching code is private to the class, it's going to be very hard to create a test case without changing some of the variables from private to package (say). This is an area that I've often wondered about -- how do most people deal with writing unit tests for this sort of stuff? In principle, I think it'd be OK to make things package instead of private, if we also seal the JAR file (i.e. add a Sealed: attribute in the manifest) to prevent application classes from declaring themselves into the org.apache.commons.beanutils package and therefore gaining access to these variables. it shouldn't be too hard to create a test case but the question is whether it's worth altering the API to do so. if the general feeling is that a test case for this issue is worth making this change, i'll take a look at writing one now. - robert Craig On Friday, October 18, 2002, at 07:29 PM, Scott Sanders wrote: With the exception of 12728/12458. I have not yet looked at creating a test case for it, but I do believe the patch is solid. I have attached it if you get a chance to look at it. Other than that, I think we are ready. Scott -Original Message- From: robert burrell donkin [mailto:robertburrelldonkin;blueyonder.co.uk] Sent: Friday, October 18, 2002 11:24 AM To: Jakarta Commons Developers List Subject: [beanutils] ready for 1.5 release? are we ready for a beanutils 1.5 release? - robert -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache. org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache. org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache. org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache. org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [sql] Refactor JDBCTransformTast?
From: Craig R. McClanahan [EMAIL PROTECTED] On Fri, 18 Oct 2002 [EMAIL PROTECTED] wrote: Interesting ... I was looking at the same class for the same reason recently. My thought was to split the JDBC--XML functionality into two pieces: JDBC--Internal graph of objects starting with o.a.c.s.model.Database, and Object Graph-XML (which already exists via DatabaseWriter). That way, a tool or app that wanted to introspect a set of database metadata, and then use it directly, could do so without having to do it in two steps. Agreed. Thats always been the intention. Then a model-diff could be implemented for determining the DDL required to perform a schema upgrade, to compare the database changes required when upgrading software or to test if a real database has the required schema that a codebase expects etc. One question I had when looking at this, though ... the data model represented in the XML document format doesn't totally match that represented in the o.a.c.s.model package classes. Shouldn't it? It should. I'm sure we can fix it fairly easily. The model needs to be extended a bit right now for indices and maybe extend the relationship support a little. I've been chatting to some of the middlegen folks lately http://boss.bekk.no/boss/middlegen/ who might use commons-sql as the database model on which their UI and Ant/XDoclet tools will generate JDO, CMP and other code from. A few minor extensions to commons-sql model will be required to facilitate this (like supporting relationship cardinality etc). James --- http://radio.weblogs.com/0112098/ __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons/logging/src/test/org/apache/commons/logging LogTest.java AbstractLogTest.java TestAll.java
rsitze 2002/10/19 10:14:26
Modified:logging/src/test/org/apache/commons/logging
AbstractLogTest.java TestAll.java
Added: logging/src/test/org/apache/commons/logging LogTest.java
Log:
- Added new LogTest that exercises factory
- log statements now show implementation class
(helpfull for visual verification that expected logger was found).
Revision ChangesPath
1.5 +18 -13
jakarta-commons/logging/src/test/org/apache/commons/logging/AbstractLogTest.java
Index: AbstractLogTest.java
===
RCS file:
/home/cvs/jakarta-commons/logging/src/test/org/apache/commons/logging/AbstractLogTest.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- AbstractLogTest.java 18 Oct 2002 04:19:56 - 1.4
+++ AbstractLogTest.java 19 Oct 2002 17:14:26 - 1.5
-86,53 +86,58
assertNotNull(log);
+
log.debug(null);
log.debug(null, null);
- log.debug(debug statement);
+ log.debug(log.getClass().getName() + : debug statement);
- log.debug(debug statement w/ null exception, new RuntimeException());
+ log.debug(log.getClass().getName() + : debug statement w/ null
exception, new RuntimeException());
+
log.error(null);
log.error(null, null);
- log.error(error statement);
+ log.error(log.getClass().getName() + : error statement);
- log.error(error statement w/ null exception, new RuntimeException());
+ log.error(log.getClass().getName() + : error statement w/ null
exception, new RuntimeException());
+
log.fatal(null);
log.fatal(null, null);
- log.fatal(fatal statement);
+ log.fatal(log.getClass().getName() + : fatal statement);
- log.fatal(fatal statement w/ null exception, new RuntimeException());
+ log.fatal(log.getClass().getName() + : fatal statement w/ null
exception, new RuntimeException());
+
log.info(null);
log.info(null, null);
- log.info(info statement);
+ log.info(log.getClass().getName() + : info statement);
- log.info(info statement w/ null exception, new RuntimeException());
+ log.info(log.getClass().getName() + : info statement w/ null
exception, new RuntimeException());
+
log.trace(null);
log.trace(null, null);
- log.trace(trace statement);
+ log.trace(log.getClass().getName() + : trace statement);
+
+ log.trace(log.getClass().getName() + : trace statement w/ null
exception, new RuntimeException());
- log.trace(trace statement w/ null exception, new RuntimeException());
log.warn(null);
log.warn(null, null);
- log.warn(warn statement);
-
- log.warn(warn statement w/ null exception, new RuntimeException());
+ log.warn(log.getClass().getName() + : warn statement);
+ log.warn(log.getClass().getName() + : warn statement w/ null
exception, new RuntimeException());
}
}
1.4 +5 -4
jakarta-commons/logging/src/test/org/apache/commons/logging/TestAll.java
Index: TestAll.java
===
RCS file:
/home/cvs/jakarta-commons/logging/src/test/org/apache/commons/logging/TestAll.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- TestAll.java 11 Oct 2002 04:53:21 - 1.3
+++ TestAll.java 19 Oct 2002 17:14:26 - 1.4
-88,6 +88,7
suite.addTest(SimpleLogTest.suite());
suite.addTest(NoOpLogTest.suite());
+suite.addTest(LogTest.suite());
return suite;
}
1.1
jakarta-commons/logging/src/test/org/apache/commons/logging/LogTest.java
Index: LogTest.java
===
package org.apache.commons.logging;
import org.apache.commons.logging.impl.SimpleLog;
import junit.framework.*;
/**
*
*
*
*
*
*
*/
public class LogTest extends AbstractLogTest
{
/**
*
*
* param
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang StringUtils.java
bayard 2002/10/19 10:18:50
Modified:lang/src/java/org/apache/commons/lang StringUtils.java
Log:
Javadoc fixing patch applied form Fredrik Westermark
Revision ChangesPath
1.19 +240 -226
jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java
Index: StringUtils.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- StringUtils.java 30 Sep 2002 00:50:10 - 1.18
+++ StringUtils.java 19 Oct 2002 17:18:49 - 1.19
-70,9 +70,9
* author a href=mailto:gcoladonato;yahoo.comGreg Coladonato/a
* author a href=mailto:bayard;generationjava.comHenri Yandell/a
* author a href=mailto:ed;apache.orgEd Korthof/a
- * author a href=mailto:rand_mcneely;yahoo.comRand McNeely/a
- * author a href=mailto:scolebourne;joda.orgStephen Colebourne/a
- * author a href=mailto:fredrik;westermarck.comFredrik Westermarck/a
+ * author a href=mailto:rand_mcneely;yahoo.comRand McNeely/a
+ * author a href=mailto:scolebourne;joda.orgStephen Colebourne/a
+ * author a href=mailto:fredrik;westermarck.comFredrik Westermarck/a
* version $Id$
*/
public class StringUtils {
-90,11 +90,11
//--
/**
- * Removes control characters, including whitespace, from both ends of this
- * string, handling null by returning an empty string.
+ * Removes control characters, including whitespace, from both ends of this
+ * String, handling codenull/code by returning an empty String.
*
* see java.lang.String#trim()
- * param str the string to check
+ * param str the String to check
* return the trimmed text (never codenull/code)
*/
public static String clean(String str) {
-102,11 +102,11
}
/**
- * Removes control characters, including whitespace, from both ends of this
- * string, handling null by returning null.
+ * Removes control characters, including whitespace, from both ends of this
+ * String, handling codenull/code by returning codenull/code.
*
* see java.lang.String#trim()
- * param str the string to check
+ * param str the String to check
* return the trimmed text (or codenull/code)
*/
public static String trim(String str) {
-118,8 +118,8
* Spaces are defined as {' ', '\t', '\r', '\n', '\b'}
* in line with the deprecated Character.isSpace
*
- * param str String target to delete spaces from
- * return the text without spaces
+ * param str String target to delete spaces from
+ * return the String without spaces
* throws NullPointerException
*/
public static String deleteSpaces(String str) {
-127,11 +127,11
}
/**
- * Deletes all whitespace from a String.
+ * Deletes all whitespaces from a String.
* Whitespace is defined by Character.isWhitespace
*
- * param str String target to delete whitespace from
- * return the text without whitespace
+ * param str String target to delete whitespace from
+ * return the String without whitespaces
* throws NullPointerException
*/
public static String deleteWhitespace(String str) {
-148,7 +148,7
/**
* Checks if a String is non null and is not empty (length 0).
*
- * param str the string to check
+ * param str the String to check
* return true if the String is non-null, and not length zero
*/
public static boolean isNotEmpty(String str) {
-156,10 +156,10
}
/**
- * Checks if a (trimmed) String is null or empty.
+ * Checks if a (trimmed) String is codenull/code or empty.
*
- * param str the string to check
- * return true if the String is null, or length zero once trimmed
+ * param str the String to check
+ * return true if the String is codenull/code, or length zero once trimmed
*/
public static boolean isEmpty(String str) {
return (str == null || str.trim().length() == 0);
-169,40 +169,41
//--
/**
- * Compares two Strings, returning true if they are equal.
- * Nulls are handled without exceptions. Two codenull/code
- * references are considered equal. Comparison is case sensitive.
+ * Compares two Strings, returning codetrue/code if they are equal.
+ * codenull/codes are handled without exceptions. Two codenull/code
+ * references are considered to be equal. The comparison is case sensitive.
*
cvs commit: jakarta-commons/logging/src/java/org/apache/commons/logging/impl SimpleLog.java
rsitze 2002/10/19 10:19:05 Modified:logging/src/java/org/apache/commons/logging/impl SimpleLog.java Log: Dump stack trace through logger, not stdout (preservers sequence of buffered output). Revision ChangesPath 1.5 +10 -5 jakarta-commons/logging/src/java/org/apache/commons/logging/impl/SimpleLog.java Index: SimpleLog.java === RCS file: /home/cvs/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/SimpleLog.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- SimpleLog.java15 Jun 2002 20:54:48 - 1.4 +++ SimpleLog.java19 Oct 2002 17:19:05 - 1.5 -360,7 +360,12 buf.append( ); buf.append(t.toString()); buf.append(); -t.printStackTrace(); + +java.io.StringWriter sw= new java.io.StringWriter(1024); +java.io.PrintWriter pw= new java.io.PrintWriter(sw); +t.printStackTrace(pw); +pw.close(); +buf.append(sw.toString()); } // print to System.err -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13157] - LogFactory property with Log4j
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13157. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13157 LogFactory property with Log4j [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-10-19 17:23 --- Lots of logic got changed to make this work, helpfull if a few would verify that I haven't broken anything OTHER than overly friendly attitude to Log4J :-) -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons/logging/src/java/org/apache/commons/logging/impl LogFactoryImpl.java
rsitze 2002/10/19 10:25:04
Modified:logging/src/java/org/apache/commons/logging/impl
LogFactoryImpl.java
Log:
- code cleanup, refactoring, and corrected a few undiscoved bugs..
- Bugzilla 13157 - Log4j takes undue precedence over Log override.
Revision ChangesPath
1.17 +66 -55
jakarta-commons/logging/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java
Index: LogFactoryImpl.java
===
RCS file:
/home/cvs/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- LogFactoryImpl.java 27 Sep 2002 02:16:44 - 1.16
+++ LogFactoryImpl.java 19 Oct 2002 17:25:04 - 1.17
-152,6 +152,9
org.apache.commons.logging.log;
+private static final String LOG4JLOGIMPL =
+org.apache.commons.logging.impl.Log4JCategoryLog.intern();
+
// - Instance Variables
-169,6 +172,11
/**
+ * Name of the class implementing the Log interface.
+ */
+private String logClassName;
+
+/**
* The one-argument constructor of the
* {link org.apache.commons.logging.Log}
* implementation class that will be used to create new instances.
-213,8 +221,8
public Object getAttribute(String name) {
if( proxyFactory != null )
return proxyFactory.getAttribute( name );
-return (attributes.get(name));
+return attributes.get(name);
}
-236,8 +244,7
for (int i = 0; i results.length; i++) {
results[i] = (String) names.elementAt(i);
}
-return (results);
-
+return results;
}
-250,14 +257,11
* exception LogConfigurationException if a suitable codeLog/code
* instance cannot be returned
*/
-public Log getInstance(Class clazz)
-throws LogConfigurationException
-{
+public Log getInstance(Class clazz) throws LogConfigurationException {
if( proxyFactory != null )
return proxyFactory.getInstance(clazz);
-return (getInstance(clazz.getName()));
-
+return getInstance(clazz.getName());
}
-278,9 +282,7
* exception LogConfigurationException if a suitable codeLog/code
* instance cannot be returned
*/
-public Log getInstance(String name)
-throws LogConfigurationException
-{
+public Log getInstance(String name) throws LogConfigurationException {
if( proxyFactory != null )
return proxyFactory.getInstance(name);
-289,8 +291,7
instance = newInstance(name);
instances.put(name, instance);
}
-return (instance);
-
+return instance;
}
-307,7 +308,6
proxyFactory.release();
instances.clear();
-
}
-320,7 +320,6
public void removeAttribute(String name) {
if( proxyFactory != null )
proxyFactory.removeAttribute(name);
-
attributes.remove(name);
}
-336,7 +335,7
*/
public void setAttribute(String name, Object value) {
if( proxyFactory != null )
-proxyFactory.setAttribute(name,value);
+proxyFactory.setAttribute(name, value);
if (value == null) {
attributes.remove(name);
-350,34 +349,19
// -- Protected Methods
-/**
- * pReturn the codeConstructor/code that can be called to instantiate
- * new {link org.apache.commons.logging.Log} instances./p
- *
- * pstrongIMPLEMENTATION NOTE/strong - Race conditions caused by
- * calling this method from more than one thread are ignored, because
- * the same codeConstructor/code instance will ultimately be derived
- * in all circumstances./p
- *
- * exception LogConfigurationException if a suitable constructor
- * cannot be returned
- */
-protected Constructor getLogConstructor()
-throws LogConfigurationException {
-
-// Return the previously identified Constructor (if any)
-if (logConstructor != null) {
-return (logConstructor);
-}
+protected String getLogClassName() {
// Identify the Log implementation class we will be using
-String logClassName = null;
-if (logClassName == null) {
-logClassName = (String) getAttribute(LOG_PROPERTY);
+if (logClassName != null) {
+return logClassName;
}
cvs commit: jakarta-commons/logging/src/java/org/apache/commons/logging LogFactory.java
rsitze 2002/10/19 10:25:18
Modified:logging/src/java/org/apache/commons/logging LogFactory.java
Log:
- code cleanup, refactoring, and corrected a few undiscoved bugs..
- Bugzilla 13157 - Log4j takes undue precedence over Log override.
Revision ChangesPath
1.14 +47 -36
jakarta-commons/logging/src/java/org/apache/commons/logging/LogFactory.java
Index: LogFactory.java
===
RCS file:
/home/cvs/jakarta-commons/logging/src/java/org/apache/commons/logging/LogFactory.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- LogFactory.java 17 Oct 2002 23:00:04 - 1.13
+++ LogFactory.java 19 Oct 2002 17:25:18 - 1.14
-79,13 +79,14
* pFactory for creating {link Log} instances, with discovery and
* configuration features similar to that employed by standard Java APIs
* such as JAXP./p
- *
+ *
* pstrongIMPLEMENTATION NOTE/strong - This implementation is heavily
* based on the SAXParserFactory and DocumentBuilderFactory implementations
* (corresponding to the JAXP pluggability APIs) found in Apache Xerces./p
*
* author Craig R. McClanahan
* author Costin Manolache
+ * author Richard A. Sitze
* version $Revision$ $Date$
*/
-102,7 +103,6
public static final String FACTORY_PROPERTY =
org.apache.commons.logging.LogFactory;
-
/**
* The fully qualified class name of the fallback codeLogFactory/code
* implementation class to use, if no other can be found.
-110,7 +110,6
public static final String FACTORY_DEFAULT =
org.apache.commons.logging.impl.LogFactoryImpl;
-
/**
* The name of the properties file to search for.
*/
-239,9 +238,10
* ul
* liThe codeorg.apache.commons.logging.LogFactory/code system
* property./li
+ * liThe JDK 1.3 Service Discovery mechanism/li
* liUse the properties file codecommons-logging.properties/code
* file, if found in the class path of this class. The configuration
- * file is in standard codejava.util.Propertis/code format and
+ * file is in standard codejava.util.Properties/code format and
* contains the fully qualified name of the implementation class
* with the key being the system property defined above./li
* liFall back to a default implementation class
-272,6 +272,25
if (factory != null)
return factory;
+
+// Load properties file..
+// will be used one way or another in the end.
+
+Properties props=null;
+try {
+InputStream stream = (contextClassLoader == null
+ ? ClassLoader.getSystemResourceAsStream(
FACTORY_PROPERTIES )
+ : contextClassLoader.getResourceAsStream(
FACTORY_PROPERTIES ));
+if (stream != null) {
+props = new Properties();
+props.load(stream);
+stream.close();
+}
+} catch (IOException e) {
+} catch (SecurityException e) {
+}
+
+
// First, try the system property
try {
String factoryClass = System.getProperty(FACTORY_PROPERTY);
-282,6 +301,7
; // ignore
}
+
// Second, try to find a service by using the JDK1.3 jar
// discovery mechanism. This will allow users to plug a logger
// by just placing it in the lib/ directory of the webapp ( or in
-319,8 +339,6
}
-Properties props=null;
-
// Third try a properties file.
// If the properties file exists, it'll be read and the properties
// used. IMHO ( costin ) System property and JDK1.3 jar service
-329,28 +347,16
// the webapp, even if a default logger is set at JVM level by a
// system property )
-try {
-InputStream stream = (contextClassLoader == null
- ? ClassLoader.getSystemResourceAsStream(
FACTORY_PROPERTIES )
- : contextClassLoader.getResourceAsStream(
FACTORY_PROPERTIES ));
-if (stream != null) {
-props = new Properties();
-props.load(stream);
-stream.close();
-String factoryClass = props.getProperty(FACTORY_PROPERTY);
-if( factory==null ) {
-if (factoryClass == null) {
-factoryClass = FACTORY_DEFAULT;
-}
-factory = newFactory(factoryClass, contextClassLoader);
-}
+if (factory == nullprops
DO NOT REPLY [Bug 9743] - Security policy configuration, SimpleLog uses System.getProperties()
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9743. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9743 Security policy configuration, SimpleLog uses System.getProperties() --- Additional Comments From [EMAIL PROTECTED] 2002-10-19 17:34 --- This cannot be easily corrected: On one hand, SimpleLog has a requirement to pickup unspecified properties (those properties beginning with a prefix) describing logging levels for different categories. On the other, SimpleLog has turned into a real (although simple :-) log implementation. This leaves us with THREE choices for satisfactorily resolving this defect: 1. Simplify SimpleLog remove offending code, or 2. Make SimpleLog a NotSoSimpleLog with it's own property file, and remove offending calls to System.getProperties() - use property file instead. 3. Acknowledge that in a proper J2EE environment SimpleLog may not be the best answer, so it doesn't matter anyway... -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 9599] - Problem accessing LogFactoryImpl from servlet
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9599. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9599 Problem accessing LogFactoryImpl from servlet [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-10-19 17:37 --- Other recent bug fixes may have resolved this. Close pending further info. -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [general] checkstyle report
Are you talking about the maven checkstyle report? Or a specific projects? Stephen - Original Message - From: John Keyes [EMAIL PROTECTED] I would be interested to hear people's opinions on the resolution of checkstyle's error reporting. There are two options, one is to correct the code style so it conforms to the checkstyle settings, the other is to modify the settings to be less stringent. IMO, it would be great to have a common style across commons. I do think there would be opposition if this became a requirement though so I think relaxing the checkstyle properties is probably the way to go. What do others think? -John K -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
jakarta-commons - apache-commons
All: As previously mentioned on this list, there is ongoing apache-wide discussions aimed at reorganizing the apache software foundation. These discussions are taking place on the [EMAIL PROTECTED] mailing list[1]. Also mentioned here briefly, is that the apache board recently voted to create an apache commons project (at the same level of jakarta). This project is still currently in the process of being formed in terms of structure. There is light discussion about this on the [EMAIL PROTECTED] mailing list[2]. Recently, on the reorg list, Costin Manolache, made the following proposal: Ok, let's take this - I assume Java will be one of the languages in the new commons. Why not move the current jakarta-commons as the java-language sub-project of the apache-commons. As for flamewar - as long as we can keep our ties with jakarta ( and now build ties to xml ) - I suspect most people will be happy. Actually, a much better idea would be to join the xml-commons with jakarta-commons and form the self-managed java side of apache-commons. With all commiters forming the PMC. There are quite a few people in xml.apache.org who are interested in participating in jakarta-commons ( and some are actually doing so ). Of course, the first step would be to ask the question on jakarta-commons and xml-commons and eventually put it to a vote. That's the only way to know - and avoids any flamewar. Consider this as a proposal. I should reiterate here that apache commons has not fully formed, so at this point there is no definition on how it is setup or how it works. The first few projects in apache commons will probably have a hand in shaping it to some degree. So, as mentioned in his proposal, I'm sending the question to jakarta-commons. What do committers here think? Is this something we would want to consider? regards, michael [1] You can subscribe to the mailing list by sending a mail to [EMAIL PROTECTED] [2] You can subscribe to the mailing list by sending a mail to [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [general] checkstyle report
Yeap I'm on about the maven checkstyle report. -John K On Saturday, Oct 19, 2002, at 23:24 Europe/Dublin, Stephen Colebourne wrote: Are you talking about the maven checkstyle report? Or a specific projects? Stephen - Original Message - From: John Keyes [EMAIL PROTECTED] I would be interested to hear people's opinions on the resolution of checkstyle's error reporting. There are two options, one is to correct the code style so it conforms to the checkstyle settings, the other is to modify the settings to be less stringent. IMO, it would be great to have a common style across commons. I do think there would be opposition if this became a requirement though so I think relaxing the checkstyle properties is probably the way to go. What do others think? -John K -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons/httpclient/xdocs contributors.xml
rsitze 2002/10/19 15:32:04 Modified:httpclient .cvsignore httpclient/xdocs contributors.xml Log: Cleaning up, I'm using httpclient in another project, and my XML validator just choked! Revision ChangesPath 1.4 +1 -0 jakarta-commons/httpclient/.cvsignore Index: .cvsignore === RCS file: /home/cvs/jakarta-commons/httpclient/.cvsignore,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- .cvsignore25 Aug 2002 16:29:26 - 1.3 +++ .cvsignore19 Oct 2002 22:32:04 - 1.4 -5,3 +5,4 .project maven.log velocity.log +bin 1.8 +2 -2 jakarta-commons/httpclient/xdocs/contributors.xml Index: contributors.xml === RCS file: /home/cvs/jakarta-commons/httpclient/xdocs/contributors.xml,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- contributors.xml 8 Aug 2002 01:54:01 - 1.7 +++ contributors.xml 19 Oct 2002 22:32:04 - 1.8 -1,4 +1,4 -?xml version=1.0? +?xml version=1.0 encoding=ISO-8859-1? document properties titleContributors/title -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [general] checkstyle report
On lang, changing the line length to 120 helped a lot. Also, I don't know if maven is on checkstyle 2.4, but if so it has a setting to deal with RuntimeException throws clauses in javadoc correctly which should be set Stephen - Original Message - From: John Keyes [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Saturday, October 19, 2002 11:29 PM Subject: Re: [general] checkstyle report Yeap I'm on about the maven checkstyle report. -John K On Saturday, Oct 19, 2002, at 23:24 Europe/Dublin, Stephen Colebourne wrote: Are you talking about the maven checkstyle report? Or a specific projects? Stephen - Original Message - From: John Keyes [EMAIL PROTECTED] I would be interested to hear people's opinions on the resolution of checkstyle's error reporting. There are two options, one is to correct the code style so it conforms to the checkstyle settings, the other is to modify the settings to be less stringent. IMO, it would be great to have a common style across commons. I do think there would be opposition if this became a requirement though so I think relaxing the checkstyle properties is probably the way to go. What do others think? -John K -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [general] checkstyle report
I know about how to fix these but what I was asking was was a more general topic. As a good deal of the commons projects inherit the POM from the CVS root I was wondering if it would be a good idea to have a the checkstyle properties set at this level also so all of the 'mavenized' projects pick up the same settings. I think this mail is perhaps a bit more coherent ;) -John K On Saturday, Oct 19, 2002, at 23:47 Europe/Dublin, Stephen Colebourne wrote: On lang, changing the line length to 120 helped a lot. Also, I don't know if maven is on checkstyle 2.4, but if so it has a setting to deal with RuntimeException throws clauses in javadoc correctly which should be set Stephen - Original Message - From: John Keyes [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Saturday, October 19, 2002 11:29 PM Subject: Re: [general] checkstyle report Yeap I'm on about the maven checkstyle report. -John K On Saturday, Oct 19, 2002, at 23:24 Europe/Dublin, Stephen Colebourne wrote: Are you talking about the maven checkstyle report? Or a specific projects? Stephen - Original Message - From: John Keyes [EMAIL PROTECTED] I would be interested to hear people's opinions on the resolution of checkstyle's error reporting. There are two options, one is to correct the code style so it conforms to the checkstyle settings, the other is to modify the settings to be less stringent. IMO, it would be great to have a common style across commons. I do think there would be opposition if this became a requirement though so I think relaxing the checkstyle properties is probably the way to go. What do others think? -John K -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [general] checkstyle report
I would certainly support setting these two things at the commons level. But beyond that I would reckon that sticking with the checkstyle defaults is about right. Over time, I reckon the projects will slowly fall into line. Stephen - Original Message - From: John Keyes [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Saturday, October 19, 2002 11:54 PM Subject: Re: [general] checkstyle report I know about how to fix these but what I was asking was was a more general topic. As a good deal of the commons projects inherit the POM from the CVS root I was wondering if it would be a good idea to have a the checkstyle properties set at this level also so all of the 'mavenized' projects pick up the same settings. I think this mail is perhaps a bit more coherent ;) -John K On Saturday, Oct 19, 2002, at 23:47 Europe/Dublin, Stephen Colebourne wrote: On lang, changing the line length to 120 helped a lot. Also, I don't know if maven is on checkstyle 2.4, but if so it has a setting to deal with RuntimeException throws clauses in javadoc correctly which should be set Stephen - Original Message - From: John Keyes [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Saturday, October 19, 2002 11:29 PM Subject: Re: [general] checkstyle report Yeap I'm on about the maven checkstyle report. -John K On Saturday, Oct 19, 2002, at 23:24 Europe/Dublin, Stephen Colebourne wrote: Are you talking about the maven checkstyle report? Or a specific projects? Stephen - Original Message - From: John Keyes [EMAIL PROTECTED] I would be interested to hear people's opinions on the resolution of checkstyle's error reporting. There are two options, one is to correct the code style so it conforms to the checkstyle settings, the other is to modify the settings to be less stringent. IMO, it would be great to have a common style across commons. I do think there would be opposition if this became a requirement though so I think relaxing the checkstyle properties is probably the way to go. What do others think? -John K -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
RE: [general] checkstyle report
By default, I believe Mavenised projects are configured for the Sun coding conventions. Maven also directly supports the Turbine conventions, but you can modify either set, or define an entirely new set, on a per-project basis. There are Commons components that use each of these alternatives. The Commons charter allows each component to define its own set of coding conventions, as long as the conventions are documented. The default is the Sun coding conventions, if nothing else is stated. The bottom line is that each project gets to choose whether to change the code to adhere to a specific set of conventions, or modify the conventions to suit the existing code. -- Martin Cooper -Original Message- From: John Keyes [mailto:jbjk;mac.com] Sent: Saturday, October 19, 2002 2:31 PM To: commons-dev Subject: [general] checkstyle report Hi all, I would be interested to hear people's opinions on the resolution of checkstyle's error reporting. There are two options, one is to correct the code style so it conforms to the checkstyle settings, the other is to modify the settings to be less stringent. IMO, it would be great to have a common style across commons. I do think there would be opposition if this became a requirement though so I think relaxing the checkstyle properties is probably the way to go. What do others think? -John K -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
