Re: [lang] Mutable* increment decrement, add and subtract
I'm all for simplicity so not trying to catch overflow conditions is fine by me as long as we document appropriately. On 3/19/06, Stephen Colebourne [EMAIL PROTECTED] wrote: I would like to add the following methods to the Mutable* number classes - increment - decrement - addValue(int/short/...) - addValue(Number) - subtractValue(int/short/...) - subtractValue(Number) Only question is whether we should try to catch overflow conditions or not. That could get quite complex. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] (c) 404-693-4148 (o) 404-260-2382 Take back the web - http://www.mozilla.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][POLL] What JDK Version are you using?
On 1/23/06, Niall Pemberton [EMAIL PROTECTED] wrote: What JDK version are you using? - [ ] JDK 1.2 [ ] JDK 1.3 [X ] JDK 1.4 [ ] JDK 1.5 (or JDK 5) - I'm mainly interested in the impact of moving Commons Valdator a minimum dependency of JDK 1.4 to use the RegExp support rather than depending on ORO. However, other commons components may be interested in your answer, so it would be useful if you could indicate which Commons components you are using (or interested in using), especially Validator :-) tia Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] commons-beanutils commons-cli commons-collections commons-digester coimmons-httpclient commons-io commons-lang commons-logging commons-validator (via Struts) -- Steven Caswell [EMAIL PROTECTED] (c) 404-693-4148 (o) 404-260-2382 Take back the web - http://www.mozilla.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] ExceptionUtils methods
I like these suggestions for method naming. On 11/13/05, Gary Gregory [EMAIL PROTECTED] wrote: Hello: I am wondering if a toXXX name is not more appropriate since you are converting rather than getting: ExceptionUtils.toMessageNoStackTrace(ex) Or simply: ExceptionUtils.toMessage(ex) Also, I wonder if 'Short' is really useful, if I give it 1000 lines, it's not short. I think you just omit the bias issue by calling it: ExceptionUtils.toMessage (ex, stackFrameCount) Here, a descriptive parameter name like stackFrameCount avoids the need to have a more complicated API name. Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Saturday, November 12, 2005 4:02 AM To: Jakarta Commons Developers List Subject: [lang] ExceptionUtils methods Could I propose some new methods for ExceptionUtils: - ExceptionUtils.getLogMessageNoStackTrace(ex) Returns a string of the form: IllegalArgumentException: Person must have a surname ClassNameNoPackage: Message - ExceptionUtils.getLogMessageShortStackTrace(ex, lines) Returns the same as above but with a short stack trace, eg for 2 lines: IllegalArgumentException: Person must have a surname at org.apache.program.ValidatePerson.validate() at org.apache.program.Validator.validate() Potentially a variation on this could filter out certain stack trace lines. All code would be carefully null protected and designed for log messages. I think this is useful, but maybe it should form part of the logging tool (as well!)? Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] (c) 404-693-4148 (o) 404-260-2382 Take back the web - http://www.mozilla.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] ExceptionUtils methods
Sounds like a good idea to me. I would probably choose to not put Log in the method names, i.e. getMessageNoStack trace and getMessageShortStackTrace, since the methods don't specifically deal with logging and there is no requirement to use the results in a log mesage. But I don;t have a strong preference either way, so if there is a concensus I'm fine with that. On 11/12/05, Stephen Colebourne [EMAIL PROTECTED] wrote: Could I propose some new methods for ExceptionUtils: - ExceptionUtils.getLogMessageNoStackTrace(ex) Returns a string of the form: IllegalArgumentException: Person must have a surname ClassNameNoPackage: Message - ExceptionUtils.getLogMessageShortStackTrace(ex, lines) Returns the same as above but with a short stack trace, eg for 2 lines: IllegalArgumentException: Person must have a surname at org.apache.program.ValidatePerson.validate() at org.apache.program.Validator.validate() Potentially a variation on this could filter out certain stack trace lines. All code would be carefully null protected and designed for log messages. I think this is useful, but maybe it should form part of the logging tool (as well!)? Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] (c) 404-693-4148 (o) 404-260-2382 Take back the web - http://www.mozilla.org
Re: commons-lang-2.1.pom
All, It looks like when I cut the commons-lang 2.1 release back in June that I did not set the ownership group or the chmod properly on the commons-lang-2.1.pom.md5 file. It looks like on Sep 23 when the file in /www/www.apache.org/dist/java-repository/commons-lang/poms were replaced, the 2.1 pom md5 didn't get written because of this oversite, so the pom and the pom,md5 were out of sync. I have cleaned this up and created a new matching pom. It should deploy on the next cycle. Sorry for causing the mismatch. On 9/23/05, Henk P. Penning [EMAIL PROTECTED] wrote: Steven, in 'www.apache.org/dist/java-repository/commons-lang/pomshttp://www.apache.org/dist/java-repository/commons-lang/poms ' the md5 of 'commons-lang-2.1.pom' is inconsistent with commons-lang-2.1.pom.md5 Please fix rsn. Thanks Henk Penning -- apache.org http://apache.org infrastructure _ Henk P. Penning, Computer Systems Group R Uithof CGN-A232 _/ \_ Dept of Computer Science, Utrecht University T +31 30 253 4106 / \_/ \ Padualaan 14, 3584CH Utrecht, the Netherlands F +31 30 251 3791 \_/ \_/ http://www.cs.uu.nl/staff/henkp.html M [EMAIL PROTECTED] \_/ -- Steven Caswell [EMAIL PROTECTED] (c) 404-693-4148 (o) 404-260-2382 Take back the web - http://www.mozilla.org
Re: [VOTE] propose Commons-Csv to Incubator
On 9/1/05, Henri Yandell [EMAIL PROTECTED] wrote: Vote to go ahead and take the wiki'd proposal for a CSV component to the Incubator. [http://wiki.apache.org/jakarta-commons/CommonsCsv] [X ] +1 [ ] -1 -- Steven Caswell [EMAIL PROTECTED] (c) 404-693-4148 (o) 404-260-2382 Take back the web - http://www.mozilla.org
Re: svn commit: r240401 - /jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/IntHashMapTest.java
I thought I had set up my Eclipse to put in the correct header but I
screwed it up.
With egg on my face thanks for catching this.
On 8/27/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: scolebourne
Date: Sat Aug 27 03:26:53 2005
New Revision: 240401
URL: http://svn.apache.org/viewcvs?rev=240401view=rev
Log:
Fix license, style and svn properties
Modified:
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/IntHashMapTest.java
(contents, props changed)
Modified:
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/IntHashMapTest.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/IntHashMapTest.java?rev=240401r1=240400r2=240401view=diff
==
---
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/IntHashMapTest.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/IntHashMapTest.java
Sat Aug 27 03:26:53 2005
@@ -1,128 +1,141 @@
-/*
- * Copyright 2005 Steven Caswell
- */
-package org.apache.commons.lang;
-
-import junit.framework.Test;
-import junit.framework.TestCase;
-import junit.framework.TestSuite;
-import junit.textui.TestRunner;
-
-/**
- *
- * @author Steven Caswell
- * @version $Id$
- */
-public class IntHashMapTest extends TestCase
-{
-
-public static void main(String[] args) {
-TestRunner.run(suite());
-}
-
-public static Test suite() {
-TestSuite suite = new TestSuite(IntHashMapTest.class);
-suite.setName(IntHashMapTest Tests);
-return suite;
-}
-
-public void testConstructor() {
-try {
-IntHashMap map = new IntHashMap(-1, 0.0f);
-fail();
-} catch (IllegalArgumentException e) {
-assertEquals(Illegal Capacity: -1, e.getMessage());
-}
-try {
-IntHashMap map = new IntHashMap(1, 0.0f);
-fail();
-} catch (IllegalArgumentException e) {
-assertEquals(Illegal Load: 0.0, e.getMessage());
-}
-IntHashMap map = new IntHashMap(0, 1.0f);
-
-try {
-IntHashMap map1 = new IntHashMap(-1);
-fail();
-} catch (IllegalArgumentException e) {
- assertEquals(Illegal Capacity: -1, e.getMessage());
-}
-IntHashMap map1 = new IntHashMap(0);
-}
-
-public void testClear() {
-IntHashMap map = new IntHashMap();
-assertNull(map.put(1, hello));
-assertNull(map.put(2, world));
-assertEquals(2, map.size());
-map.clear();
-assertEquals(0, map.size());
-}
-
-public void testContainsKey() {
-IntHashMap map = new IntHashMap();
-assertNull(map.put(1, hello));
-assertNull(map.put(2, world));
-assertEquals(2, map.size());
-assertTrue(map.containsKey(1));
-assertTrue(map.containsKey(2));
-assertFalse(map.containsKey(3));
-}
-
-public void testContains() {
-IntHashMap map = new IntHashMap();
-assertNull(map.put(1, hello));
-assertNull(map.put(2, world));
-assertEquals(2, map.size());
-assertTrue(map.containsValue(hello));
-assertTrue(map.containsValue(world));
-assertFalse(map.containsValue(goodbye));
-try {
-map.containsValue(null);
-fail();
-} catch(NullPointerException e) {
- }
-}
-
-public void testContainsValue() {
-IntHashMap map = new IntHashMap();
-assertNull(map.put(1, hello));
-assertNull(map.put(2, world));
-assertEquals(2, map.size());
-assertTrue(map.containsValue(hello));
-assertTrue(map.containsValue(world));
-assertFalse(map.containsValue(goodbye));
-try {
-map.containsValue(null);
-fail();
-} catch(NullPointerException e) {
-}
-}
-
-public void testIsEmpty() {
-IntHashMap map = new IntHashMap();
-assertTrue(map.isEmpty());
-assertNull(map.put(1, hello));
-assertEquals(1, map.size());
-assertFalse(map.isEmpty());
-}
-
-public void testPut() {
-IntHashMap map = new IntHashMap();
-assertNull(map.put(1, hello));
-assertNull(map.put(2, world));
-assertEquals(2, map.size());
-assertEquals(hello, map.put(1, hello));
-}
-
-public void testRemove() {
-IntHashMap map = new IntHashMap();
-assertNull(map.put(1, hello
Re: [lang] StrTokenizer.getCSVXxx and getTSVXxx method names.
I agree, I prefer this naming convention also. On 8/21/05, Gary Gregory [EMAIL PROTECTED] wrote: Hello All: I would prefer that the methods StrTokenizer.getCSVXxx and getTSVXxx method be camel-cased like getCsvXxx and getTsvXxx. In general I prefer to camel case acronyms to help readability when more than one acronym is used, as in getIbmSoapXml() instead of getIBMSOAPXM(). Onions? Thanks, Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] (c) 404-693-4148 (o) 404-260-2382 Take back the web - http://www.mozilla.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Using ReflectionToStringBuilder and excluding secure fields
+1
I've thought about something similar, just never did anything about
it. I like the idea of being able to exclude some fields from the
string build.
On 8/4/05, Gary Gregory [EMAIL PROTECTED] wrote:
Hello:
Right now, I use the code below to exclude password fields from output.
/**
* Builds a String for a toString method excluding the given field
name.
*
* @param obj
*The object to toString.
* @param excludeFieldName
*The field name to exclude
* @return The toString String.
*/
public static String toStringExcluding(Object obj, final String
excludeFieldName) {
return (new ReflectionToStringBuilder(obj) {
protected boolean accept(Field f) {
return super.accept(f)
!f.getName().equals(excludeFieldName);
}
}).toString();
}
I could imagine writing my call sites like this instead:
new ReflectionToStringBuilder(obj).setExcludeFields(new
String[]{password}).toString();
Which means adding the set/getExcludeFields() feature.
Any thoughts?
Gary
--
Steven Caswell
[EMAIL PROTECTED]
(c) 404-693-4148
(o) 404-260-2382
Take back the web - http://www.mozilla.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Clover coverage of text.VariableFormatter
Gary, I've seen the same behavior in other lang tests. The common thread is that the line contains a variable assignment. I'm guessing that Clover has a problem with this but I haven't had the cycles to do any further investigation. On 7/25/05, Gary Gregory [EMAIL PROTECTED] wrote: Oliver (or others): There is just one line of code marked with a ? by Clover in VariableFormatter. The rest of the class is covered by the unit tests: http://people.apache.org/~ggregory/commons-lang/2.2-dev/docs/clover/ I am not sure if this would be fixed by using the latest version of Clover but it means that we do not have 100% for VariableFormatter and it sure would be nice to get there. Can you shine a light on this or see if you can get that last line to get covered? Thanks, Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] text.VariableFormatter to replace Interpolation and MappedMessageFormat (WAS a [POLL])
+1 On 7/21/05, Gary Gregory [EMAIL PROTECTED] wrote: Hello: It's been two weeks since I posted the original message below and I've not heard negative comments on removing Interpolation and MappedMessageFormat from the text package in favor of VariableFormatter. I will therefore do so real soon. Please raise your hand you disagree. Thanks, Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Monday, July 04, 2005 4:07 PM To: Jakarta Commons Developers List Subject: Re: [lang][POLL] text package's mapped replace classes a.k.a. interpolation Gary Gregory wrote: I'd like to get the feel of the community on whether VariableFormat can replace Interpolation and MappedMessageFormat? These two latter classes would be removed. Certainly this will be the goal, as the current classes have too much duplication. My goal is to hopefully pick one (VariableFormat) and beef up those tests (VariableFormatTest) and start moving towards a 2.2 release with the focus being on the a small text package. A la XP: release early, release often. :-) +1 text will (it seems) consist of VariableFormat, StrTokenizer and StrBuilder. Perhaps somewhere we can find a fast thread-safe NumberFormat class too. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang] NotImplementedException getMessage() method has unexecutable code
In NotImplementedException, the getMessage() method has the following code:
public String getMessage() {
if (super.getMessage() != null) {
return super.getMessage();
} else if (cause != null) {
return cause.toString();
} else {
return null;
}
}
Because of how the constructors are coded, unless I've missed
something, super.getMessage() will always return a non-null value, so
the else blocks will never execute. Did I read this correctly? Is
there any reason to keep the additional else blocks? I'd like to
remove them if there isn't.
--
Steven Caswell
[EMAIL PROTECTED]
Take back the web - http://www.mozilla.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [csv] Creating a CSV component (2)
I have an interest in the outcome so I'm willing to volunteer my time and efforts. On 7/13/05, robert burrell donkin [EMAIL PROTECTED] wrote: On Mon, 2005-07-11 at 21:37 -0400, Henri Yandell wrote: On 7/7/05, robert burrell donkin [EMAIL PROTECTED] wrote: On Thu, 2005-06-30 at 00:15 -0400, Henri Yandell wrote: snip So my proposal is that we submit Netcetera's CSV library to the ASF Incubator, with Jakarta (more correctly Jakarta Commons) acting as the sponsoring project. (I'd be happy to volunteer to be mentor the project). While in the Incubator we would add more unit tests on the code side, and make sure legal issues are comfortably handled. +1 (i was thinking about creating a post saying the same) has this moved over to incubator yet? if not, maybe someone could put up a wiki page giving an idea what needs to be done... Researching what would need to be done now. Sorry for the long delay on all this. Time to get some momentum. thanks for the hard work picking this up :) There are two threads in this, turning Netcetera's component into a Commons component, and how does the Commons want to use the Incubator. On the first subject: snip 2) Who are our initial list of committers? Any Commons committer; do the original authors wish to be committers on the codebase? Are Simon Hefti and Ronnie Brunner prospective committers? good question :) anyone want to speak up? 3) Obviously we would mavenise, repackage and improve javadoc/unit-tests if need be. Anything else that would need to be done to the codebase? dunno creating a list is probably the first job once the code's in the incubator - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang] Revisiting empty statements one more time (last time I promise)
Gary and Stephen (and anyone else who might care ;) I'd like to take one more stab at convincing you guys that an empty statement denoted by a semicolon would be a better approach to indicate no action than just using a comment. I promise I'll move on if this is not convincing enough. So here we go: - Empty statement is defined by the language so while it may look odd it is in fact a valid Java statement - Since it is a legal Java statement, it is parsable and shows up in ASTs. Comments are discarded and do not show up in ASTs - Any tool that uses an AST approach to examining source constructs (such as PMD) can be told to look for and handle an empty statement. Tools that use ASTs cannot be told to look for comments. IMHO, having the statement parsable and recognizable by tools gives the most flexibility at a pretty small price. The empty statement doesn't affect logic at all, and doesn't affect performance in the tests I've done. It seems a small price to pay (a bit of adjustment in reading the code) for the benefit. If a line with a single semicolon is not acceptable, is there some other parsable construct that would be? Thanks for the indulgence. -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Revisiting empty statements one more time (last time I promise)
It could possible be done using the GenericIllegalRegexp check. I'm
not a regexp guru so I'm not sure if an appropriate regexp could be
written, but knowing how powerful regexps are I wouldn't be surprised.
On 7/4/05, Gary Gregory [EMAIL PROTECTED] wrote:
} catch (SomeException ignored) {
Interesting thought! Somehow, I do not think that checkstyle can do
that. Can it?
Gary
-Original Message-
From: sebb [mailto:[EMAIL PROTECTED]
Sent: Monday, July 04, 2005 10:23 AM
To: Jakarta Commons Developers List
Subject: Re: [lang] Revisiting empty statements one more time (last
time I
promise)
How about:
try
{
...
} catch (SomeException ignored) {
// We do nothing here because the try block checked
// the widget and logged an error in the fizbang.
}
i.e. use a special variable name that can then be checked in the
compiled
code.
S.
On 7/4/05, Gary Gregory [EMAIL PROTECTED] wrote:
Hello:
I am against using a lone ;. IMHO I think that what shows up in an
AST
is irrelevant in this case and actually a problem with the source
checking tool. Let's think about the real problem, which I claim is
this:
try {
// a
// bunch
// of
// stuff
} catch (SomeException e) {
}
My claim: Undocumented empty blocks and especially empty catch
blocks
are a BAD THING. I have Eclipse set up to give a compile warning on
undocumented empty blocks and on empty statements. Of course,
not
everyone uses Eclipse and whatever source-checking we use tools will
not
have the same features as Eclipse.
What you really want, I claim, is this:
} catch (SomeException e) {
// We do nothing here because the try block checked
// the widget and logged an error in the fizbang.
}
Allowing the following is no good IMO as there is no explanation:
} catch (SomeException e) {
;
}
And this is no good either IMO:
} catch (SomeException e) {
;
// We do nothing here because the try block checked
// the widget and logged an error in the fizbang.
}
I want a source checking tool to tell me about undocumented empty
blocks
because that is a maintenance problem. As long as there is no
comment,
there is a problem IMO. Allowing solo-; is just plain old confusing
to
me and does NOT add any value to the source.
As I've stated before, because some tools need to have the source
massaged a certain way is not a good reason to muck up the source,
it
just points to a deficiency in the tool.
I hope the above convinces folks too ;-)
Gary
-Original Message-
From: Steven Caswell [mailto:[EMAIL PROTECTED]
Sent: Monday, July 04, 2005 9:17 AM
To: Jakarta Commons Developers List
Subject: [lang] Revisiting empty statements one more time (last
time I
promise)
Gary and Stephen (and anyone else who might care ;)
I'd like to take one more stab at convincing you guys that an
empty
statement denoted by a semicolon would be a better approach to
indicate no action than just using a comment. I promise I'll move
on
if this is not convincing enough.
So here we go:
- Empty statement is defined by the language so while it may look
odd
it is in fact a valid Java statement
- Since it is a legal Java statement, it is parsable and shows up
in
ASTs. Comments are discarded and do not show up in ASTs
- Any tool that uses an AST approach to examining source
constructs
(such as PMD) can be told to look for and handle an empty
statement.
Tools that use ASTs cannot be told to look for comments.
IMHO, having the statement parsable and recognizable by tools
gives
the most flexibility at a pretty small price. The empty statement
doesn't affect logic at all, and doesn't affect performance in the
tests I've done. It seems a small price to pay (a bit of
adjustment in
reading the code) for the benefit.
If a line with a single semicolon is not acceptable, is there some
other parsable construct that would be?
Thanks for the indulgence.
--
Steven Caswell
[EMAIL PROTECTED]
Take back the web - http://www.mozilla.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED
[lang] Adjustment to BitField
While looking at the coverage of test cases, I noticed the following in the BitField class: If I create a BitField with a mask of 0, then invoke isAllSet(0), the return value is true, instead of false as I expected. Is there any particular reason the method should behave this way, or should it indeed return false? TIA -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Lang] text. Interpolation, on to 2.2
Gary, I'm not finding the variable format classes in the repository. Maybe I'm missing something. Can you send a link? Thanks. On 7/3/05, Gary Gregory [EMAIL PROTECTED] wrote: Hello all: I've stored a (slightly mood's) version of Oliver's classes (includes tests) from http://issues.apache.org/bugzilla/show_bug.cgi?id=35588 in CVS. I'd like to discuss what we think of using Variable Format (which can be renamed to something better if someone can think of a better name). Adopting Variable Format would mean removing Interpolation and MappedMessageFormat. Thoughts? Thanks, Gary -Original Message- From: Gary Gregory [mailto:[EMAIL PROTECTED] Sent: Sunday, July 03, 2005 1:40 PM To: Jakarta Commons Developers List Subject: RE: [lang] text.Interpolation, on to 2.2 Thank you Oliver. I'll be taking a look over the weekend. Gary -Original Message- From: Oliver Heger [mailto:[EMAIL PROTECTED] Sent: Saturday, July 02, 2005 11:42 AM To: Jakarta Commons Developers List Subject: Re: [lang] text.Interpolation, on to 2.2 Gary Gregory wrote: Oliver, Would you be willing to have a go at creating these classes for lang? Thanks, Gary A first implementation can be found at the new BZ ticket 35588: http://issues.apache.org/bugzilla/show_bug.cgi?id=35588 Comments are welcome! Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [csv] Creating a CSV component (2)
Sounds like a good approach to me. I'm definitely +1 and hope to have some cycles to help with the unit tests. On 6/30/05, Henri Yandell [EMAIL PROTECTED] wrote: On 6/27/05, Stefan Rufer [EMAIL PROTECTED] wrote: I dare to come back to the Creating a CSV component thread where the discussion has starved a bit during the last weeks: http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200506.mbox/[EMAIL PROTECTED] Summary: So far I've found the following oppinions concerning CSV as an own Jakarta Commons component: Henri Yandell +1 Kevin Gessner -1 (rather inlcude in [lang] or [io]) Jeremias Maerki +1 Steven Caswell +1 Thorsten Curdt +1 Henri presented different code offerings a CSV component can be based on (Netcetera, OSJava). There were no comments about this. Any more input? I had to back off to focus on the board report (for a week), and have spent the last week digging into Infrastructure issues (SVN migrations). Getting back on csv, the Netcetera code seems to clearly be the best choice. Something which has been nibbling away at my mind for the last week is that, for a basic csv component, it's more than complete and I'm not sure we would immediately have a direction to want to add lots of features, so it seems to me that this is a case where Commons should be going through the Incubator and not just adding the code in. Netcetera have a couple of ASF committers already, whom I think have been volunteered to be initial committers (need to ask them at some point :) ), and we've enough interest in Commons that I think getting through the Incubator will be no problem, but using the Incubator would be a good education for the Commons community; we've not had a lot to do with it so far. So my proposal is that we submit Netcetera's CSV library to the ASF Incubator, with Jakarta (more correctly Jakarta Commons) acting as the sponsoring project. (I'd be happy to volunteer to be mentor the project). While in the Incubator we would add more unit tests on the code side, and make sure legal issues are comfortably handled. Check http://incubator.apache.org/ out for more info. What do you all think? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang] customizing the PMD report [WAS Re: added empty statement to empty catch blocks [WAS: svn commit: r202043 - in /jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang: NumberUtils.java SerializationUtils.java enum/Enum.java enums/E
As I mentioned peviously, I added an empty statement to catch blocks
because an empty catch block is not a good thing and an empty
statement is a way to at least show there was a modicum of thought to
having the catch do nothing. The empty statement works for some style
checkers like Checkstyle but doesn't work with the default setting in
PMD (it get reported as an empty statement outside a loop). I propose
to add a custom ruleset to the PMD report generated by maven to
include the catch block as an allowable place for an empty statement.
On 6/27/05, Steven Caswell [EMAIL PROTECTED] wrote:
Yep. In this case throwing a bone to the PMD checker.Of course if I
had actually rerun the PMD report before committing I would have
realized that it also doesn't like an empty statement outside of a
loop, so I really didn't fix anything PMD-wise. I'll have to rethink
that particular bone.
On 6/27/05, James Carman [EMAIL PROTECTED] wrote:
Some style checkers won't allow you to have empty code blocks. You must at
least have one empty statement.
-Original Message-
From: Gary Gregory [mailto:[EMAIL PROTECTED]
Sent: Monday, June 27, 2005 4:54 PM
To: Jakarta Commons Developers List
Subject: added empty statement to empty catch blocks [WAS: svn commit:
r202043 - in
/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang:
NumberUtils.java SerializationUtils.java enum/Enum.java enums/Enum.java
math/NumberUtils.java]
Hello:
What is the reason for this change?
-//Too big for a long
+; //Too big for a long
It looks very odd to me.
Thanks,
Gary
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, June 27, 2005 1:24 PM
To: [EMAIL PROTECTED]
Subject: svn commit: r202043 - in
/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang:
NumberUtils.java SerializationUtils.java enum/Enum.java enums/Enum.java
math/NumberUtils.java
Author: stevencaswell
Date: Mon Jun 27 13:24:10 2005
New Revision: 202043
URL: http://svn.apache.org/viewcvs?rev=202043view=rev
Log:
added empty statement to empty catch blocks
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/Numbe
rUtils.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/Seria
lizationUtils.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enum/
Enum.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums
/Enum.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/math/
NumberUtils.java
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/Numbe
rUtils.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/src/java
/org/apache/commons/lang/NumberUtils.java?rev=202043r1=202042r2=202043
view=diff
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/Numbe
rUtils.java (original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/Numbe
rUtils.java Mon Jun 27 13:24:10 2005
@@ -197,7 +197,7 @@
try {
return createLong(numeric);
} catch (NumberFormatException nfe) {
-//Too big for a long
+; //Too big for a long
}
return createBigInteger(numeric);
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/Seria
lizationUtils.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/src/java
/org/apache/commons/lang/SerializationUtils.java?rev=202043r1=202042r2
=202043view=diff
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/Seria
lizationUtils.java (original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/Seria
lizationUtils.java Mon Jun 27 13:24:10 2005
@@ -114,7 +114,7 @@
out.close();
}
} catch (IOException ex) {
-// ignore;
+; // ignore
}
}
}
@@ -170,7 +170,7 @@
in.close();
}
} catch (IOException ex) {
-// ignore
+; // ignore
}
}
}
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enum/
Enum.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/src/java
/org/apache/commons/lang/enum/Enum.java?rev=202043r1=202042r2=202043v
iew=diff
[lang] customizing the PMD report [WAS: Re: added empty statement to empty catch blocks [WAS: svn commit: r202043 - in /jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang: NumberUtils.java SerializationUtils.java enum/Enum.java enums/
As I mentioned peviously, I added an empty statement to catch blocks
because an empty catch block is not a good thing and an empty
statement is a way to at least show there was a modicum of thought to
having the catch do nothing. The empty statement works for some style
checkers like Checkstyle but doesn't work with the default setting in
PMD (it get reported as an empty statement outside a loop). I propose
to add a custom ruleset to the PMD report generated by maven to
include the catch block as an allowable place for an empty statement.
On 6/27/05, Steven Caswell [EMAIL PROTECTED] wrote:
Yep. In this case throwing a bone to the PMD checker.Of course if I
had actually rerun the PMD report before committing I would have
realized that it also doesn't like an empty statement outside of a
loop, so I really didn't fix anything PMD-wise. I'll have to rethink
that particular bone.
On 6/27/05, James Carman [EMAIL PROTECTED] wrote:
Some style checkers won't allow you to have empty code blocks. You must at
least have one empty statement.
-Original Message-
From: Gary Gregory [mailto:[EMAIL PROTECTED]
Sent: Monday, June 27, 2005 4:54 PM
To: Jakarta Commons Developers List
Subject: added empty statement to empty catch blocks [WAS: svn commit:
r202043 - in
/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang:
NumberUtils.java SerializationUtils.java enum/Enum.java enums/Enum.java
math/NumberUtils.java]
Hello:
What is the reason for this change?
-//Too big for a long
+; //Too big for a long
It looks very odd to me.
Thanks,
Gary
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, June 27, 2005 1:24 PM
To: [EMAIL PROTECTED]
Subject: svn commit: r202043 - in
/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang:
NumberUtils.java SerializationUtils.java enum/Enum.java enums/Enum.java
math/NumberUtils.java
Author: stevencaswell
Date: Mon Jun 27 13:24:10 2005
New Revision: 202043
URL: http://svn.apache.org/viewcvs?rev=202043view=rev
Log:
added empty statement to empty catch blocks
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/Numbe
rUtils.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/Seria
lizationUtils.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enum/
Enum.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums
/Enum.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/math/
NumberUtils.java
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/Numbe
rUtils.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/src/java
/org/apache/commons/lang/NumberUtils.java?rev=202043r1=202042r2=202043
view=diff
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/Numbe
rUtils.java (original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/Numbe
rUtils.java Mon Jun 27 13:24:10 2005
@@ -197,7 +197,7 @@
try {
return createLong(numeric);
} catch (NumberFormatException nfe) {
-//Too big for a long
+; //Too big for a long
}
return createBigInteger(numeric);
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/Seria
lizationUtils.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/src/java
/org/apache/commons/lang/SerializationUtils.java?rev=202043r1=202042r2
=202043view=diff
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/Seria
lizationUtils.java (original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/Seria
lizationUtils.java Mon Jun 27 13:24:10 2005
@@ -114,7 +114,7 @@
out.close();
}
} catch (IOException ex) {
-// ignore;
+; // ignore
}
}
}
@@ -170,7 +170,7 @@
in.close();
}
} catch (IOException ex) {
-// ignore
+; // ignore
}
}
}
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enum/
Enum.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/src/java
/org/apache/commons/lang/enum/Enum.java?rev=202043r1=202042r2=202043v
iew=diff
Re: [lang] customizing the PMD report [WAS Re: added empty statement to empty catch blocks [WAS: svn commit: r202043 - in /jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang: NumberUtils.java SerializationUtils.java enum/Enum.java enu
Actually, I was proposing to leave the ; in to mark the empty
statement (sorry I wasn't clear).This is the simplest way to make PMD
know about the empty statement.
On 6/29/05, Gary Gregory [EMAIL PROTECTED] wrote:
I am +1 on removing the ; and making the style checker behave with
reason.
IMHO, an empty catch block is OK IFF it is { // documented in-line }. I
have my Eclipse settings set to warn me of this but I know not everyone
uses Eclipse.
Gary
-Original Message-
From: Steven Caswell [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 29, 2005 1:41 PM
To: Jakarta Commons Developers List
Subject: [lang] customizing the PMD report [WAS Re: added empty
statement to empty catch blocks [WAS: svn commit: r202043 - in
/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang:
NumberUtils.java SerializationUtils.java enum/Enum.java enums/E
As I mentioned peviously, I added an empty statement to catch blocks
because an empty catch block is not a good thing and an empty
statement is a way to at least show there was a modicum of thought to
having the catch do nothing. The empty statement works for some style
checkers like Checkstyle but doesn't work with the default setting in
PMD (it get reported as an empty statement outside a loop). I propose
to add a custom ruleset to the PMD report generated by maven to
include the catch block as an allowable place for an empty statement.
On 6/27/05, Steven Caswell [EMAIL PROTECTED] wrote:
Yep. In this case throwing a bone to the PMD checker.Of course if I
had actually rerun the PMD report before committing I would have
realized that it also doesn't like an empty statement outside of a
loop, so I really didn't fix anything PMD-wise. I'll have to rethink
that particular bone.
On 6/27/05, James Carman [EMAIL PROTECTED] wrote:
Some style checkers won't allow you to have empty code blocks. You
must at
least have one empty statement.
-Original Message-
From: Gary Gregory [mailto:[EMAIL PROTECTED]
Sent: Monday, June 27, 2005 4:54 PM
To: Jakarta Commons Developers List
Subject: added empty statement to empty catch blocks [WAS: svn
commit:
r202043 - in
/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang:
NumberUtils.java SerializationUtils.java enum/Enum.java
enums/Enum.java
math/NumberUtils.java]
Hello:
What is the reason for this change?
-//Too big for a long
+; //Too big for a long
It looks very odd to me.
Thanks,
Gary
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, June 27, 2005 1:24 PM
To: [EMAIL PROTECTED]
Subject: svn commit: r202043 - in
/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang:
NumberUtils.java SerializationUtils.java enum/Enum.java
enums/Enum.java
math/NumberUtils.java
Author: stevencaswell
Date: Mon Jun 27 13:24:10 2005
New Revision: 202043
URL: http://svn.apache.org/viewcvs?rev=202043view=rev
Log:
added empty statement to empty catch blocks
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/Numbe
rUtils.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/Seria
lizationUtils.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enum/
Enum.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums
/Enum.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/math/
NumberUtils.java
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/Numbe
rUtils.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/src/java
/org/apache/commons/lang/NumberUtils.java?rev=202043r1=202042r2=202043
view=diff
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/Numbe
rUtils.java (original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/Numbe
rUtils.java Mon Jun 27 13:24:10 2005
@@ -197,7 +197,7 @@
try {
return createLong(numeric);
} catch (NumberFormatException nfe) {
-//Too big for a long
+; //Too big for a long
}
return createBigInteger(numeric);
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/Seria
lizationUtils.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/src/java
/org/apache/commons/lang/SerializationUtils.java?rev=202043r1=202042r2
=202043view=diff
Re: [lang] customizing the PMD report [WAS Re: added empty statement to empty catch blocks [WAS: svn commit: r202043 - in /jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang: NumberUtils.java SerializationUtils.java enum/Enum.java enu
My reasoning behind using a semicolon is that this is the defined statement in the Language Specification for denoting an empty statement, and something that code checkers/syntax parsers/etc can easily be told to look for. One syntax, no ambiguity. As opposed to comments which are not the language-specified way to indicate an empty statement, are ambiguous, and make it difficult for checkers to discover. On 6/29/05, Stephen Colebourne [EMAIL PROTECTED] wrote: Steven Caswell wrote: Actually, I was proposing to leave the ; in to mark the empty statement (sorry I wasn't clear). I'd prefer not to have the ; if possible. It just looks and feels very odd, esp. when a comment would do logically. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: added empty statement to empty catch blocks [WAS: svn commit: r202043 - in /jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang: NumberUtils.java SerializationUtils.java enum/Enum.java enums/Enum.java math/NumberUtils.java]
} catch (InvocationTargetException e) {
-// ignore - should never happen
+; // ignore - should never happen
}
return false;
}
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums
/Enum.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/src/java
/org/apache/commons/lang/enums/Enum.java?rev=202043r1=202042r2=202043
view=diff
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums
/Enum.java (original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums
/Enum.java Mon Jun 27 13:24:10 2005
@@ -548,11 +548,11 @@
String name = (String) mth.invoke(other, null);
return iName.equals(name);
} catch (NoSuchMethodException e) {
-// ignore - should never happen
+; // ignore - should never happen
} catch (IllegalAccessException e) {
-// ignore - should never happen
+; // ignore - should never happen
} catch (InvocationTargetException e) {
-// ignore - should never happen
+; // ignore - should never happen
}
return false;
}
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/math/
NumberUtils.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/src/java
/org/apache/commons/lang/math/NumberUtils.java?rev=202043r1=202042r2=2
02043view=diff
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/math/
NumberUtils.java (original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/math/
NumberUtils.java Mon Jun 27 13:24:10 2005
@@ -456,7 +456,7 @@
try {
return createLong(numeric);
} catch (NumberFormatException nfe) {
-//Too big for a long
+; //Too big for a long
}
return createBigInteger(numeric);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Steven Caswell
[EMAIL PROTECTED]
Take back the web - http://www.mozilla.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Tagging after style changes
Sure. Since I'm mostly the style culprit I'll put on a tag when I'm done. On 6/27/05, Stephen Colebourne [EMAIL PROTECTED] wrote: As there are a lot of style changes going in at the moment, I was wondering if we could tag [lang] after they are complete. That way, comparisons when releasing v2.2 can have a better baseline to compare to that doesn't have spurious style only fixes. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r201882 - in /jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang: enum/ enums/ exception/ math/
Sounds reasonable. I'll make the code change, but I don't think there
is a checkstyle rule that will enforce it.
On 6/26/05, Stephen Colebourne [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Log:
corrected style issues (mostly empty blocks and missing javadocs)
* pRestrictive constructor./p
*/
private Entry() {
+ ; // empty constructor
}
}
I would suggest the following as a more logical way to handle this
private Entry() {
+super();
}
Personally, I believe that constructors should always have a this() or
super(), and in fact that is the checkstyle rule I would prefer to see ;-)
Stephen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Steven Caswell
[EMAIL PROTECTED]
Take back the web - http://www.mozilla.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] text.Interpolation, on to 2.2
Though I don't really have bandwidth to help with it, I am +1 on
moving forward with Interpolation being a motivation for the next
release.
On 6/23/05, Gary Gregory [EMAIL PROTECTED] wrote:
Hello:
Is anyone planning on working on text.Interpolation in the near future?
It seems like a logical candidate and a motivation for the next release.
Where does the class come from and does it make sense to simply extract
some code out of Ant.
I could see a subclass dealing specifically with this. Something like:
Interpolation si = new SystemPropertyInterpolation();
// replace all system property in ${} with real values.
string = si.interpolateAll(string);
The class name does seem a little pedantic to me, but eh, I can't come
up with something more succinct right now ;-)
Thoughts?
Thanks,
Gary
--
Steven Caswell
[EMAIL PROTECTED]
Take back the web - http://www.mozilla.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[lang][patch] Implementation of escape/unescapeHtml methods with Writer
http://issues.apache.org/bugzilla/show_bug.cgi?id=35366 contains a replacement for the escape/unescape methods. The comment in the original code says to rewrite to use a Writer. The patch actually changes the method signature to pass in a Writer and have the method write into it. Is that the intention of the comment? Do we want to deprecate the existing method or just add an additional overloaded method? -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Board meeting on June 22nd
On 6/15/05, Henri Yandell [EMAIL PROTECTED] wrote: Need subreports for: Commons-Lang Done. -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] [digester] [VOTE] release version 1.7 - REPOST
Just one question about the jar: The manifest indicates the jar was built with JDK 1.5. Does this present any issues with running against previous Java versions? Thanks. On 6/11/05, Phil Steitz [EMAIL PROTECTED] wrote: +1 Phil On 6/10/05, Simon Kitching [EMAIL PROTECTED] wrote: Hi All, Unfortunately there have been absolutely no responses to my request for votes to release digester 1.7 so far. The release candate RC2 is here: http://people.apache.org/~skitching/digester-1.7/ This was reviewed by Phil Steitz, who found only a few very minor items that have been addressed: http://marc.theaimsgroup.com/?l=jakarta-commons-userm=111777409621992w=2 In addition, Blake Meike has been testing his application with the RC release and had no problems: http://marc.theaimsgroup.com/?l=jakarta-commons-userm=111817438332427w=2 It seems reasonable therefore to ask for your votes so we can get this release out the door. So *please* take a few minutes to check that the right procedures have been followed, then add your +1 vote so the release can be completed. Thanks, Simon On Wed, 2005-06-08 at 12:19 +1200, Simon Kitching wrote: Hi, As we've had two release candidates, and there have been no major issues raised, I would appreciate your votes to approve an official release. Phil Steitz raised a couple of minor points for RC2 that have been addressed; the changes since RC2 are: * removed tabs from unit-test and example files * added comments to file build.properties.sample These changes don't seem worth rolling another RC for. So: should RC2+trivial changes be released as digester 1.7? [ ] +1, yes [ ] -1, no Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [all] [digester] [VOTE] release version 1.7 - REPOST
That's cool. Here is my +1. On 6/11/05, Simon Kitching [EMAIL PROTECTED] wrote: On Sat, 2005-06-11 at 19:50 -0400, Steven Caswell wrote: Just one question about the jar: The manifest indicates the jar was built with JDK 1.5. Does this present any issues with running against previous Java versions? File project.properties contains this: # generate .class files that can be loaded into a version 1.2 JVM. # Digester requires java1.2 collection classes, so doesn't support # 1.1 JVMs. maven.compile.target=1.2 maven.compile.source=1.2 So the .class files in the jar are useable in any 1.2 JVM, despite being compiled via JDK 1.5. I have tested this and the jar works fine with java 1.3. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] Preparing for 2.1 release
That document is a great start, but it stops at the point I need the most help on :-\ I'm looking for how to proceed once the release has actually been cut: things like updating the web site, deploying the distributions, distributing the announcement, etc. Any write-ups or assistance would be welcome. TIA On 6/9/05, Simon Kitching [EMAIL PROTECTED] wrote: On Thu, 2005-06-09 at 16:03 -0400, Steven Caswell wrote: I'm planning to cut the 2.1 release this weekend if there aren't any -1s before then, and I've never done one of these, so I'm wondering if there is any doc anywhere I can look at for steps/guidelines/etc. Failing that, is there someone who would be so kind as to give me the pointers I need to get the release done. Sounds good. A link to information on creating a release can be found on the commons page navbar under releasing components. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] Preparing for 2.1 release
You know, there is something in my browser software that turns on links just as soon as I hit the send button (just kidding). Just after I send this email I found the link on the page Simon referenced. Sorry for the noise. On 6/11/05, Steven Caswell [EMAIL PROTECTED] wrote: That document is a great start, but it stops at the point I need the most help on :-\ I'm looking for how to proceed once the release has actually been cut: things like updating the web site, deploying the distributions, distributing the announcement, etc. Any write-ups or assistance would be welcome. TIA On 6/9/05, Simon Kitching [EMAIL PROTECTED] wrote: On Thu, 2005-06-09 at 16:03 -0400, Steven Caswell wrote: I'm planning to cut the 2.1 release this weekend if there aren't any -1s before then, and I've never done one of these, so I'm wondering if there is any doc anywhere I can look at for steps/guidelines/etc. Failing that, is there someone who would be so kind as to give me the pointers I need to get the release done. Sounds good. A link to information on creating a release can be found on the commons page navbar under releasing components. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
[VOTE][RESULT][lang] VOTE 2.1 release based on RC8
The vote to release common-lang 2.1 has passed. The following people voted on release Lang 2.1: Steven Caswell +1 Simon Kitching+1 Gary Gregory +1 Phil Steitz+1 Michael Heuer +1 Fredrik Westermarck +1 Stephen Colebourne +1 I will be cutting the release shortly. On 6/6/05, Steven Caswell [EMAIL PROTECTED] wrote: Now that RC8 (http://www.apache.org/~stevencaswell/commons-lang-2.1) has been up for a few days with no issues, I propose it becomes the 2.1 release. [ ] +1 [ ] -1 -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [csv] Creating a CSV component
I'm also +1 to a separate [csv] component for the reasons already conveyed. On 6/9/05, Jeremias Maerki [EMAIL PROTECTED] wrote: I must say that I agree with Henri that this merits its own component. IMO it doesn't fit into [lang] and would look strange within [io] or [codec]. CSV is a topic that comes up every now and then and if this could be solved once and for all then a separate component would be justified if only for it to be easily found which it wouldn't be if it were hidden in one of the existing packages. Too bad I don't have time to help. CSV stuff bit me more than a couple of times in the past. Thanks to Henri for putting some energy into it. On 09.06.2005 06:09:13 Kevin Gessner wrote: On 6/8/05, Henri Yandell [EMAIL PROTECTED] wrote: snip Another question is where the code should go. [lang] and [io] have been suggested, as has a [csv] component. I'll go as far as to say that [csv] is the direction we should go and see if anybody disagrees :) Some sort of CVS utility sounds like a smashing idea. But I respectfully disagree with your placement, Hen. I don't see why we would need a whole new component for something that comfortably fits into [io] or [lang]. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
[lang] Preparing for 2.1 release
I'm planning to cut the 2.1 release this weekend if there aren't any -1s before then, and I've never done one of these, so I'm wondering if there is any doc anywhere I can look at for steps/guidelines/etc. Failing that, is there someone who would be so kind as to give me the pointers I need to get the release done. TIA -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] Stopwatch javadoc (2.1 RC8)
I don't see any problem with keeping the change. I agree that a new RC isn't necessary (we've done this a couple of times already on doc changes). On 6/7/05, Stephen Colebourne [EMAIL PROTECTED] wrote: I have just committed a change to fix the javadoc of StopWatch. This is a javadoc only change. Ideally, this should go in 2.1, as this class was a key changed class in 2.1 and the javadoc did not explain the changes (in fact it was inaccurate). Steven (as release manager), feel free to rollback the change if you want to get the release out. (My opinion is that this would not require a new RC, your opinion may differ ;-) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] CloneUtils
I generally like small classes with few methods, but a significant exception to that is utility classes. In this case I prefer the kind of thing we've done with StringUtils. That way, when there is string manipulation to be done, I know exactly where to go to look, without having to drag out sveral classes hunting the right method. So I'm +1 on multiple methods with nice names. On 6/7/05, Stephen Colebourne [EMAIL PROTECTED] wrote: I like the idea of multiple methods with nice names. I'm not averse to a CloneUtils class (it could be argued that StringUtils is too big as one class, or that it is most convenient as one class...) Perhaps others can comment on the location of the new methods. Stephen Kevin Gessner wrote: Kind of what I had in mind, but I'm not sure why serialization would be the last-attempted method. It's guaranteed to work for any Serializable without mucking about with reflection, so it should probably go first. We should also add support for Externalizables (as rare as they often are). I hacked up some code based on Serialization cloning, which I could send along. I don't think this should nec'ly go in with ObjectUtils. Each of the techniques of cloning would be its own method, with something like a cloneAll(Object o) that would try each in turn. I think this would make ObjectUtils messy, and CloneUtils would tie it together nicely. Kevin On 6/6/05, Stephen Colebourne [EMAIL PROTECTED] wrote: OK, here is the definition of CloneUtils as originally in my mind: See PrototypeFactory in [collections]. It clones an object by a) public method named cloned (called by reflection) b) public copy constructor c) serialization (trying each in turn until one suceeds) IMHO, this would now be written as ObjectUtils.clone(Object). (serialization is merely a means to an end, otherwise it would sit with [io]) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
[lang] VOTE 2.1 release based on RC8
Now that RC8 (http://www.apache.org/~stevencaswell/commons-lang-2.1) has been up for a few days with no issues, I propose it becomes the 2.1 release. [ ] +1 [ ] -1 -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] VOTE 2.1 release based on RC8
My +1 On 6/6/05, Steven Caswell [EMAIL PROTECTED] wrote: Now that RC8 (http://www.apache.org/~stevencaswell/commons-lang-2.1http://www.apache.org/%7Estevencaswell/commons-lang-2.1) has been up for a few days with no issues, I propose it becomes the 2.1release. [X ] +1 [ ] -1 -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] VOTE 2.1 release based on RC8
Gary, Actually, I had thought I had regened the RC8 with those but I actually had not made the replacements to the download area. All is in place now. The two changes were the RELEASE-NOTES.txt and the Tasks report in the maven docs. On 6/6/05, Gary Gregory [EMAIL PROTECTED] wrote: Hello: Does this version include the mod to RELEASE-NOTES.txt to note the JUnit dependency? IOW, has the RC8 been regened with just those little changes? I think there was another small change someone had mentioned post RC8? Thanks, Gary -Original Message- From: Steven Caswell [mailto:[EMAIL PROTECTED] Sent: Monday, June 06, 2005 4:40 PM To: Jakarta Commons Developers List Subject: [lang] VOTE 2.1 release based on RC8 Now that RC8 (http://www.apache.org/~stevencaswell/commons-lang-2.1) has been up for a few days with no issues, I propose it becomes the 2.1 release. [ ] +1 [ ] -1 -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] TODOs
Kevin, On the todo list, I know these items are about to be included in the 2.1release any day now: DateRange DurationFormatUtils CharUtils Mutable Number classes Of the remaining items, examples and documentation are always welcome. I know some work has been done on some tokenizing, but I don't know the exact status. Folks as always are busy, so if you don't get more specific responses in a few days, pick one you are interested in, research the prior discussions, and talk to the list with some suggestions. On 5/31/05, Kevin Gessner [EMAIL PROTECTED] wrote: Hello all, I'm interested in helping out on the lang project, and was wondering what TODOs might be outstanding. I saw the Tasks Outstanding page at http://jakarta.apache.org/commons/lang/tasks.html, but have any of these have been started/completed, or are there any additions? I'd rather not duplicate someone's work by mistake! I saw (in the mailing list archives) that DateRange has been completed, but I'm interested in the status of anything else. Thanks, Kevin Gessner [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] Release Candidiate 8 available
I agree with Gary. I don't have a problem putting the junit.jar into the ant
lib folder. Simon has a good point about documenting the dependency. IMHO
there should be a mention in the release notes with a fuller explanation in
the developer's guide. I'll take a first cut and we can dress it up from
there.
On 6/1/05, Gary Gregory [EMAIL PROTECTED] wrote:
Hello:
I think it is quite reasonable to use the junit task to invoke junit
tests, IMO it is the best way since it is both clear and succinct.
Invoking junit tests the old way feels to me like a bit of hack, it just
happens to work by some side effect. Using the junit task states: This
is a junit test, run!
Personally, I would not favor the taskdef approach. My view on the
subject is that one's development environment has to be set up in a
certain way and JUnit is part of that. We already need Java, Ant and
Maven. JUnit in Ant is another layer.
We can always change is back of course ;-)
Gary
-Original Message-
From: Simon Kitching [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 01, 2005 5:36 AM
To: Jakarta Commons Developers List
Subject: RE: [lang] Release Candidiate 8 available
On Wed, 2005-06-01 at 01:55 -0400, Gary Gregory wrote:
Simon:
You probably need to copy junit.jar to %ANT_HOME%\lib
Yep, that will make things work. But I'm questioning whether it is
reasonable for the lang 2.1 build process to require users to do this.
What is wrong with the old way of running junit?
Alternatively, according to the documentations the junit ant task will
work if the classpath tag is used to point to the junit jar. And there
is already a property defined for that, right? So maybe the build.xml
could be modified to provide an explicit taskdef for junit?
Below is an example from the FAQ:
taskdef name=junit
class=org.apache.tools.ant.taskdefs.optional.junit.JUnitTask
classpath
pathelement location=${junit.jar}/
pathelement location=NEW-HOME-OF/ant-junit.jar/
/classpath
/taskdef
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Steven Caswell
[EMAIL PROTECTED]
Take back the web - http://www.mozilla.org
Re: [lang] Release Candidiate 8 available
It looks like checkstyle.xml is the file that is required and that checkstyle.properties is no longer used. It is easy enough to copy checkstyle.xml into the source distribution, but that alone won't enable maven site:generate to be run on the unzipped source. Various pieces of the maven setup require commons-build to also be available, so I'm not sure that it is necessary that the source distribution pass site:generate. I think passing test:test should be sufficient. I propose we wait until after the release and then remove checkstyle.properties. There should be plenty of time from there to verify it really isn't used. On 6/1/05, Gary Gregory [EMAIL PROTECTED] wrote: Hello All: I have run the following with success on Window XP SP2 based on unzipping http://people.apache.org/~stevencaswell/commons-lang-2.1/distributions/c ommons-lang-2.1-RC8-src.zip. Ant 1.6.4 with the command ant clean dist-build-2.1 test with: Sun Java 1.5.0_03 Sun Java 1.4.2_08 Sun Java 1.3.1_14 Maven 1.0.2 with the command maven clean site:generate (for all Sun java versions above) always gives me: BUILD FAILED File.. C:\Documents and Settings\ggregory.SSSI\.maven\cache\maven-checkstyle-plugin-2.5\plugin.j elly Element... ant:checkstyle Line.. 144 Column 63 Unable to create a Checker: unable to find file:checkstyle.xml Total time: 5 seconds Finished at: Tue May 31 23:06:42 PDT 2005 The checkstyle file(s) are missing from the src dist. Do we still need BOTH checkstyle.properties and checkstyle.xml in SVN? Thanks, Gary -Original Message- From: Steven Caswell [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 31, 2005 7:38 PM To: Jakarta Commons Developers List Subject: [lang] Release Candidiate 8 available Commons-lang 2.1 release candidate 8 is available at http://www.apache.org/~stevencaswell/commons-lang-2.1/ Primary change is Gary's working out the oddball build and class loading issue that only seems to happen on Windows XP (SP2) since Simon reports that the ant build works fine for him on Linux. As with previous RCs, verification against as many JDK versions would be appreciated, and a sanity check of the docs would also be welcome. Vote to follow if no reports of problems. -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] 2.1RC7 and java 1.4
Gary, Glad to hear you've made progress. I will build another RC this evening. On 5/31/05, Gary Gregory [EMAIL PROTECTED] wrote: Hello: I've finally worked out the oddball build and class loading issue that only seems to happen on Windows XP (SP2) since Simon reports that the ant build works fine for him on Linux. I can report success with ant clean dist-build-2.1 test on Sun Java versions: 1.5.0_03 1.5.0_02 1.4.2_08 1.3.1_14 In order achieve this; the new build.xml depends on Ant 1.6. Version 1.2.2_017 hangs miserably for me though, as it did before any of these changes. [alas, it probably means another RC though]. Yes, please. Thanks, Gary -Original Message- From: Simon Kitching [mailto:[EMAIL PROTECTED] Sent: Monday, May 30, 2005 12:40 AM To: Jakarta Commons Developers List Subject: RE: [lang] 2.1RC7 and java 1.4 On Sun, 2005-05-29 at 11:34 -0400, Gary Gregory wrote: Here is what I propose baring any -1s from others: I'll make the changes noted below while still using the old test invocation style for the Enum/Enums test. This last class loading problem being a weird one. Hm, now that I think about it the Enum/Enums will still fail on either 1.3 (no fix: old error; with fix: new class loading problem), sigh. I guess I or someone else should dig into the class loading issue, which only happens from the Ant CLI, not when I run the tests from Eclipse. I'll just note (again) that all the unit tests work FINE for me with the Ant CLI (and the Maven CLI), on java 1.2.2, 1.3.1, 1.5.0 (all on Linux). Not that I have any objection to depending on ant 1.6 for builds if people want to [alas, it probably means another RC though]. Hmm.. one thing I just noticed though. Normally, foo-src.tar.gz files unpack into a directory named foo-src. But commons-lang-2.1-RC7-src.tar.gz unpacks into a directory commons-lang-2.1-RC7. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
[lang] Release Candidiate 8 available
Commons-lang 2.1 release candidate 8 is available at http://www.apache.org/~stevencaswell/commons-lang-2.1/ Primary change is Gary's working out the oddball build and class loading issue that only seems to happen on Windows XP (SP2) since Simon reports that the ant build works fine for him on Linux. As with previous RCs, verification against as many JDK versions would be appreciated, and a sanity check of the docs would also be welcome. Vote to follow if no reports of problems. -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] 2.1RC7 and java 1.4 [WAS:] DateUtils test fails under 1.2.2 and not under 1.4.2
I actually overlooked your e-mail on this when I back through to decide if
we had resolved everything and I apologize for that.
I don't have any problem with your prosal to make Ant 1.6 a prereq, so I'll
put in my +1.
On 5/29/05, Gary Gregory [EMAIL PROTECTED] wrote:
Hello:
Note that RC7 does not change any of the issues in this message thread.
The suggestions below cause one odd problem though: For the enum tests,
an ClassNotFoundException is thrown when trying to load the Enum class
from the custom built class loader. Weird.
Gary
-Original Message-
From: Gary Gregory
Sent: Friday, May 27, 2005 12:08 AM
To: 'Jakarta Commons Developers List'; [EMAIL PROTECTED]
Subject: RE: FW: [lang] DateUtils test fails under 1.2.2 and not under
1.4.2
Actually, assuming what is below is acceptable, using Ant 1.6 allows for
a clean up to make the build.xml file shorter with:
macrodef name=testit
attribute name=classname/
sequential
junit printsummary=true fork=${junit.fork}
haltonerror=${test.failonerror}
classpath refid=test.classpath/
test name=@{classname}/
/junit
/sequential
/macrodef
target name=test.lang depends=compile.tests
testit classname=org.apache.commons.lang.LangTestSuite/
/target
!-- Ditto for all test targets. --
Any thoughts on making Ant 1.6 a build pre-req?
Gary
-Original Message-
From: Gary Gregory [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 26, 2005 10:56 PM
To: Jakarta Commons Developers List; [EMAIL PROTECTED]
Subject: RE: FW: [lang] DateUtils test fails under 1.2.2 and not under
1.4.2
Hello Steven and All:
Here is a fix for build problems on Sun Java 1.3.1 and 1.2.2.
Instead of using this odd way of invoking unit tests:
target name=test.lang depends=compile.tests
echo message=Running lang package tests .../
java classname=${test.runner} fork=${test.fork}
failonerror=${test.failonerror}
arg value=org.apache.commons.lang.LangTestSuite/
classpath refid=test.classpath/
/java
/target
I changed this target on my machine to the more standard JUnit
invocation:
target name=test.lang depends=compile.tests
echo message=Running lang package tests .../
junit fork=${junit.fork} haltonerror=${test.failonerror}
classpath refid=test.classpath/
test name=org.apache.commons.lang.LangTestSuite/
/junit
/target
The test passed on 1.4.2_08, 1.3.1_14 and 1.2.2_017.
Shall I (or Steven) change the JUnit invocation style for all tests?
Gary
-Original Message-
From: Simon Kitching [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 26, 2005 9:07 PM
To: Jakarta Commons Developers List
Subject: Re: FW: [lang] DateUtils test fails under 1.2.2 and not under
1.4.2
On Thu, 2005-05-26 at 20:05 -0400, Steven Caswell wrote:
That is so very odd. I'm at a loss to explain it. I don't have access
to a
system with JDK 1.3 so I'm not able to try it. Maybe someone else can
try?
I've also tried building with JDK1.2.2 on linux.
I got this as part of the output
[java] Java 1.3 tests not run since the current version is 1.2.2
and also got the DateUtilsTest.testRound failure.
No other problems were encountered.
If Gary is running tests on Windows, then his problem might indicate a
windows-specific issue. Otherwise it looks to me like a system-specific
problem with Gary's setup.
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Steven Caswell
[EMAIL PROTECTED]
Take back the web - http://www.mozilla.org
[lang] Release Candidiate 7 available
Commons-lang 2.1 RC7 is now available at http://www.apache.org/~stevencaswell/commons-lang-2.1/ Fixes include adjustment to org.apache.commons.lang.time.DateUtilsTest.javato avoid failing tests under versions prior to 1.4, and adjustments to the build.xml used to build the distribution with ant Test builds under as many JDKs as possible would be appreciated. Any other verification of javadocs, distributions, etc. are aslo appreciated. If there are no issues found I'll call for a vote. -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: FW: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2
That is so very odd. I'm at a loss to explain it. I don't have access to a system with JDK 1.3 so I'm not able to try it. Maybe someone else can try? One thing I did find I needed to do was to change th junit version in default.properties from 3.7 to 3.8.1. Gary, could you try making this change and building under 1.3.1? I'm just curious to see if this makes a difference, though I don't see why it should. Thanks. On 5/25/05, Gary Gregory [EMAIL PROTECTED] wrote: Steven: I updated from CVS today and got new build.xml. I still get the error below on Sun Java 1.3.1_14. Thanks, Gary -- *From:* Gary Gregory *Sent:* Tuesday, May 24, 2005 7:12 PM *To:* 'Steven Caswell' *Cc:* Jakarta Commons Developers List *Subject:* RE: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2 Steven: (You're welcome.) Downloaded RC6a-src and I am now experiencing Weirdness: I run ant clean dist-build-2.1 test which works fine on Sun Java 1.4.2_08. On Sun Java 1.3.1_14 I get: test.lang: [echo] Running lang package tests ... [java] Class not found org.apache.commons.lang.LangTestSuite BUILD FAILED C:\temp\commons-lang-2.1-RC6\build.xml:166: Java returned: 1 Which makes no sense at first glance. Gary -- *From:* Steven Caswell [mailto:[EMAIL PROTECTED] *Sent:* Tuesday, May 24, 2005 7:00 PM *To:* Gary Gregory *Cc:* Jakarta Commons Developers List *Subject:* Re: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2 Gary, I put up the revised source distribution in http://www.apache.org/~stevencaswell/commons-lang-2.1http://www.apache.org/%7Estevencaswell/commons-lang-2.1 I named them commons-lang-2.1-RC6a-src.* so you could easily tell they are modified. I was just too lazy to change it to RC7 for a minor non-code fix, and since there will probably be an RC7 with the date utils test change. Thanks for your patience and thanks for testing these things. On 5/24/05, *Steven Caswell* [EMAIL PROTECTED] wrote: Gary, I have a fix for that problem. I'll go ahead and put up a corrected source distribution with the fix and without the DateUtilsTest correction so you can try 1.3.1. On 5/24/05, *Gary Gregory* [EMAIL PROTECTED] wrote: I'd like to check 1.3.1 but... running ant clean build-dist-2.1 test from src-zip does not make it past text tests: test.text: [echo] Running text package tests ... [java] Class not found org.apache.commons.lang.text.TextTestSuite BUILD FAILED C:\temp\commons-lang-2.1-RC6\build.xml:206: Java returned: 1 Which should not be run in the 1st place... (Ant 1.6.4 and Java 1.4.2_08) Gary -Original Message- From: Steven Caswell [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 24, 2005 5:39 PM To: Jakarta Commons Developers List Subject: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2 All, I have discovered a group of tests in the DateUtils test case that fails under 1.2.2 but not under 1.4.2. They are testing the DateUtils round method when rounding a date in the MET timezone across the start and end of DST. If I remember correctly, this was in response to a user bug report. In particular the test is at line 472 of the testRound method in DataUtilsTest.java. The test passes fine when run under 1.4.2 but fails under 1.2.2. I don't have a 1.3 installation available so I don't know if it passes or fails under 1.3. I propose that we put a condition around the test so that is only run when the Java version is 1.4, and add a note to the round method javadoc and the release notes stating that the round method may not work properly in all cases involving DST rollovers in previous JVMs, with this case as an example. Thoughs? -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: FW: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2
Glad you found it. On 5/26/05, Gary Gregory [EMAIL PROTECTED] wrote: Hi: I found possible solution. With 1.3.1, if I set *fork* to *false*, the test is found and run. Weird. Gary -- *From:* Steven Caswell [mailto:[EMAIL PROTECTED] *Sent:* Thursday, May 26, 2005 5:06 PM *To:* Gary Gregory *Cc:* Jakarta Commons Developers List *Subject:* Re: FW: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2 That is so very odd. I'm at a loss to explain it. I don't have access to a system with JDK 1.3 so I'm not able to try it. Maybe someone else can try? One thing I did find I needed to do was to change th junit version in default.properties from 3.7 to 3.8.1. Gary, could you try making this change and building under 1.3.1? I'm just curious to see if this makes a difference, though I don't see why it should. Thanks. On 5/25/05, *Gary Gregory* [EMAIL PROTECTED] wrote: Steven: I updated from CVS today and got new build.xml. I still get the error below on Sun Java 1.3.1_14. Thanks, Gary -- *From:* Gary Gregory *Sent:* Tuesday, May 24, 2005 7:12 PM *To:* 'Steven Caswell' *Cc:* Jakarta Commons Developers List *Subject:* RE: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2 Steven: (You're welcome.) Downloaded RC6a-src and I am now experiencing Weirdness: I run ant clean dist-build-2.1 test which works fine on Sun Java 1.4.2_08. On Sun Java 1.3.1_14 I get: test.lang: [echo] Running lang package tests ... [java] Class not found org.apache.commons.lang.LangTestSuite BUILD FAILED C:\temp\commons-lang-2.1-RC6\build.xml:166: Java returned: 1 Which makes no sense at first glance. Gary -- *From:* Steven Caswell [mailto:[EMAIL PROTECTED] *Sent:* Tuesday, May 24, 2005 7:00 PM *To:* Gary Gregory *Cc:* Jakarta Commons Developers List *Subject:* Re: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2 Gary, I put up the revised source distribution in http://www.apache.org/~stevencaswell/commons-lang-2.1 http://www.apache.org/%7Estevencaswell/commons-lang-2.1 I named them commons-lang-2.1-RC6a-src.* so you could easily tell they are modified. I was just too lazy to change it to RC7 for a minor non-code fix, and since there will probably be an RC7 with the date utils test change. Thanks for your patience and thanks for testing these things. On 5/24/05, *Steven Caswell* [EMAIL PROTECTED] wrote: Gary, I have a fix for that problem. I'll go ahead and put up a corrected source distribution with the fix and without the DateUtilsTest correction so you can try 1.3.1. On 5/24/05, *Gary Gregory* [EMAIL PROTECTED] wrote: I'd like to check 1.3.1 but... running ant clean build-dist-2.1 test from src-zip does not make it past text tests: test.text: [echo] Running text package tests ... [java] Class not found org.apache.commons.lang.text.TextTestSuite BUILD FAILED C:\temp\commons-lang-2.1-RC6\build.xml:206: Java returned: 1 Which should not be run in the 1st place... (Ant 1.6.4 and Java 1.4.2_08) Gary -Original Message- From: Steven Caswell [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 24, 2005 5:39 PM To: Jakarta Commons Developers List Subject: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2 All, I have discovered a group of tests in the DateUtils test case that fails under 1.2.2 but not under 1.4.2. They are testing the DateUtils round method when rounding a date in the MET timezone across the start and end of DST. If I remember correctly, this was in response to a user bug report. In particular the test is at line 472 of the testRound method in DataUtilsTest.java. The test passes fine when run under 1.4.2 but fails under 1.2.2. I don't have a 1.3 installation available so I don't know if it passes or fails under 1.3. I propose that we put a condition around the test so that is only run when the Java version is 1.4, and add a note to the round method javadoc and the release notes stating that the round method may not work properly in all cases involving DST rollovers in previous JVMs, with this case as an example. Thoughs? -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: FW: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2
Simon, Thanks for the tests. Glad to hear 1.5 is clean. I found the same errors with the DateUtilsTest and I've got a fix ready to check in. I was waiting until we resolved these other issues. There is a tag for RC6 but not for the RC6a because I built it from the head and from a couple of local changes. I plan to build an RC7 with the test source and configuration fixes and cross my fingers that it will be the golden one. On 5/26/05, Simon Kitching [EMAIL PROTECTED] wrote: Hi, with lang/trunk: maven clean test works for me with java1.5 on linux ant clean dist-build-2.1 test works for me with java1.5 on linux with the contents of file commons-lang-2.1-RC6a-src.tar.gz: maven clean test works for me with java1.5 on linux ant clean dist-build-2.1 test works for me with java1.5 on linux I used junit-3.8.1 with ant. maven clean test on lang/trunk or with the download RC6a file fails with java1.3.1 on linux: [junit] Tests run: 40, Failures: 1, Errors: 0, Time elapsed: 4.995 sec [junit] [ERROR] TEST org.apache.commons.lang.time.TimeTestSuite FAILED $ cat target/test-reports/ TEST-org.apache.commons.lang.time.TimeTestSuite.txt Testcase: testRound(org.apache.commons.lang.time.DateUtilsTest): FAILED round MET date across DST change-over expected:Sun Mar 30 03:00:00 IRST 2003 but was:Sun Mar 30 02:00:00 IRST 2003 junit.framework.AssertionFailedError: round MET date across DST change-over expected:Sun Mar 30 03:00:00 IRST 2003 but was:Sun Mar 30 02:00:00 IRST 2003 at org.apache.commons.lang.time.DateUtilsTest.testRound(DateUtilsTest.java :472) $ java -version java version 1.3.1_14 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_14-b03) Java HotSpot(TM) Client VM (build 1.3.1_14-b03, mixed mode) I did not get the reported problem: [java] Class not found org.apache.commons.lang.LangTestSuite I don't see any RC6 directory under lang/tags. I presume the .tar.gz file on your site is actually from HEAD? Regards, Simon On Thu, 2005-05-26 at 20:05 -0400, Steven Caswell wrote: That is so very odd. I'm at a loss to explain it. I don't have access to a system with JDK 1.3 so I'm not able to try it. Maybe someone else can try? One thing I did find I needed to do was to change th junit version in default.properties from 3.7 to 3.8.1. Gary, could you try making this change and building under 1.3.1? I'm just curious to see if this makes a difference, though I don't see why it should. Thanks. On 5/25/05, Gary Gregory [EMAIL PROTECTED] wrote: Steven: I updated from CVS today and got new build.xml. I still get the error below on Sun Java 1.3.1_14. Thanks, Gary -- *From:* Gary Gregory *Sent:* Tuesday, May 24, 2005 7:12 PM *To:* 'Steven Caswell' *Cc:* Jakarta Commons Developers List *Subject:* RE: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2 Steven: (You're welcome.) Downloaded RC6a-src and I am now experiencing Weirdness: I run ant clean dist-build-2.1 test which works fine on Sun Java 1.4.2_08. On Sun Java 1.3.1_14 I get: test.lang: [echo] Running lang package tests ... [java] Class not found org.apache.commons.lang.LangTestSuite BUILD FAILED C:\temp\commons-lang-2.1-RC6\build.xml:166: Java returned: 1 Which makes no sense at first glance. Gary -- *From:* Steven Caswell [mailto:[EMAIL PROTECTED] *Sent:* Tuesday, May 24, 2005 7:00 PM *To:* Gary Gregory *Cc:* Jakarta Commons Developers List *Subject:* Re: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2 Gary, I put up the revised source distribution in http://www.apache.org/~stevencaswell/commons-lang-2.1 http://www.apache.org/%7Estevencaswell/commons-lang-2.1 I named them commons-lang-2.1-RC6a-src.* so you could easily tell they are modified. I was just too lazy to change it to RC7 for a minor non-code fix, and since there will probably be an RC7 with the date utils test change. Thanks for your patience and thanks for testing these things. On 5/24/05, *Steven Caswell* [EMAIL PROTECTED] wrote: Gary, I have a fix for that problem. I'll go ahead and put up a corrected source distribution with the fix and without the DateUtilsTest correction so you can try 1.3.1. On 5/24/05, *Gary Gregory* [EMAIL PROTECTED] wrote: I'd like to check 1.3.1 but... running ant clean build-dist-2.1 test from src-zip does not make it past text tests: test.text: [echo] Running text package tests ... [java] Class not found org.apache.commons.lang.text.TextTestSuite BUILD FAILED C:\temp\commons-lang-2.1-RC6\build.xml:206: Java returned: 1 Which should not be run in the 1st place... (Ant 1.6.4 and Java 1.4.2_08) Gary
Re: [lang] checkstyle report
I propose that for the upcoming lang 2.1 release we leave the errors unfixed
and leave the checkstyle report as is.
1. Leave them unfixed because the errors are all documentation-related, and
while it is important to fix them, I don't believe the problems are
detrimental to the product. It has taken long enough to get the release out
(and I take some of the blame for the slowness) and I don't believe it is
worth delaying longer to make what I consider marginally useful fixes.
Unless someone gets to them before the final RC.
2. Leave the checkstyle report as is because the problems should be fixed,
and I'm worried that if we hide them for this release then they'll be
forgotten. I'd rather take the time after the release to either fix them or
hide them after appropriate discussion, which I believe should also not hold
up the release.
Thoughts?
On 5/24/05, Simon Kitching [EMAIL PROTECTED] wrote:
Hi,
I've checked
http://people.apache.org/~stevencaswell/commons-lang-2.1/docs/checkstyle-report.html
and there is a massive number of checkstyle errors reported.
I suggest you either fix them or turn off the checkstyle checks you
don't want. Fixing the problem is probably better.
By the way, I've struck a checkstyle problem when using it in the
digester site. Despite project.properties having
maven.checkstyle.properties=${basedir}/checkstyle.xml
it doesn't look to me like the specified checkstyle.xml file is actually
being used. I can even change the contents to invalid xml and no error
is reported.
Lang has exactly the same setup for checkstyle reports. Does the
checkstyle.xml file have any effect in lang?
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Steven Caswell
[EMAIL PROTECTED]
Take back the web - http://www.mozilla.org
Re: [lang] VOTE 2.1 release (new vote based on RC6)
I would expect the error with dist-build since that target doesn't
understand there is no text package. I tried to make
dist-build-2.1understand there was not a text package but I must have
missed something.
I'll take a look.
On 5/24/05, Gary Gregory [EMAIL PROTECTED] wrote:
Hello:
The text package is now causing problems. If I run ant clean dist-build
test or ant clean dist-build-2.1 test I get:
test.text:
[echo] Running text package tests ...
[java] Class not found org.apache.commons.lang.text.TextTestSuite
BUILD FAILED
C:\temp\commons-lang-2.1-RC6\build.xml:206: Java returned: 1
Gary
--
*From:* Steven Caswell [mailto:[EMAIL PROTECTED]
*Sent:* Monday, May 23, 2005 3:28 PM
*To:* Gary Gregory
*Cc:* Jakarta Commons Developers List
*Subject:* Re: [lang] VOTE 2.1 release (new vote based on RC6)
All,
I have replaced the RC6 source distributions with new ones containing the
RELEASE-NOTES.txt file. Thanks to Gary for finding the omission.
On 5/23/05, *Steven Caswell* [EMAIL PROTECTED] wrote:
Gary,
I suspect building against 1.4.2 and running against 1.2.2 will not work
due to changes in the Java API. The RC binary distribution is in fact build
with 1.2.2, so it may be sufficient just to run the downloaded RC6 against
your 1.2.2 without building from scratch.
On 5/23/05, *Gary Gregory* [EMAIL PROTECTED] wrote:
As another data point, building with Java 1.3.1_14 ends with the same
error below as with 1.4.2_08:
BUILD FAILED
C:\temp\commons-lang-2.1-RC6\build.xml:120: The following error occurred
while executing this line:
C:\temp\commons-lang-2.1-RC6\build.xml:115: Warning: Could not find file
C:\temp\commons-lang-2.1-RC6\RELEASE-NOTES.txt to copy.
So I am thinking that there is a bug in Ant 1.6.4 when used with Sun Java
1.2.2_017.
If you can fix the missing file problem I can do a local build with 1.3.1or
1.4.2 but run the test target with 1.2.2.
Gary
--
*From:* Steven Caswell [mailto: [EMAIL PROTECTED]
*Sent:* Monday, May 23, 2005 11:26 AM
*To:* Gary Gregory
*Cc:* Jakarta Commons Developers List
*Subject:* Re: [lang] VOTE 2.1 release (new vote based on RC6)
No, my mistake, I should have looked closer. There is a reference to that
version in the javadoc generation output. So I should ask, any progress on
the 1.2.2 issue? I'm trying to imagine how the source would affect that
and I can't see how it would, at least not at the level you are seeing the
errors. Maybe a cross-pointing between 1.2 and 1.4?
On 5/23/05, *Gary Gregory* [EMAIL PROTECTED] wrote:
Sorry, I should have been clearer. If by earlier problem you mean the
hanging 1.2.2 build, it is not solved. The build below with the missing
RELEASE-NOTES.txt was run with Sun Java 1.4.2_08.
Gary
--
*From:* Steven Caswell [mailto: [EMAIL PROTECTED]
*Sent:* Monday, May 23, 2005 11:14 AM
*To:* Gary Gregory
*Cc:* Jakarta Commons Developers List
*Subject:* Re: [lang] VOTE 2.1 release (new vote based on RC6)
That seems odd since I used maven to gen the sources. Will take a look.
Looks like your earlier problem is fixed.
On 5/23/05, *Gary Gregory* [EMAIL PROTECTED] wrote:
Hello:
RELEASE-NOTES.txt is missing from:
http://people.apache.org/~stevencaswell/commons-lang-2.1/distributions/c
http://people.apache.org/%7Estevencaswell/commons-lang-2.1/distributions/c
ommons-lang-2.1-RC6-src.zip
Unzipping the above and running:
ant clean dist-build-2.1
gives the error:
Buildfile: build.xml
clean:
[delete] Deleting directory C:\temp\commons-lang-2.1-RC6\target
dist-build-2.1 :
clean:
init:
[echo] commons-lang 2.1-RC6
prepare:
[mkdir] Created dir: C:\temp\commons-lang-2.1-RC6\target
[mkdir] Created dir: C:\temp\commons-lang-2.1-RC6\target\classes
[mkdir] Created dir: C:\temp\commons-lang-2.1-RC6\target\conf
[mkdir] Created dir: C:\temp\commons-lang-2.1-RC6\target\tests
static:
[copy] Copying 1 file to C:\temp\commons-lang-2.1-RC6\target\conf
compile:
[javac] Compiling 70 source files to
C:\temp\commons-lang-2.1-RC6\target\classes
[javac]
C:\temp\commons-lang-2.1-RC6\src\java\org\apache\commons\lang\enum\EnumU
tils.java:53: warning: org.apache.commons.lang.enum.Enum in
org.apache.commons.lang.en
um has been deprecated
[javac] public static Enum getEnum(Class enumClass, String name)
{
[javac] ^
[javac]
C:\temp\commons-lang-2.1-RC6\src\java\org\apache\commons\lang\enum\Value
dEnum.java:137: warning: org.apache.commons.lang.enum.Enum in
org.apache.commons.lang.
enum has been deprecated
[javac] protected static Enum getEnum(Class enumClass, int
value) {
[javac] ^
[javac]
C:\temp\commons-lang-2.1-RC6\src\java\org\apache\commons\lang\enum\EnumU
tils.java:65: warning: org.apache.commons.lang.enum.ValuedEnum
[lang] DateUtils test fails under 1.2.2 and not under 1.4.2
All, I have discovered a group of tests in the DateUtils test case that fails under 1.2.2 but not under 1.4.2. They are testing the DateUtils round method when rounding a date in the MET timezone across the start and end of DST. If I remember correctly, this was in response to a user bug report. In particular the test is at line 472 of the testRound method in DataUtilsTest.java. The test passes fine when run under 1.4.2 but fails under 1.2.2. I don't have a 1.3 installation available so I don't know if it passes or fails under 1.3. I propose that we put a condition around the test so that is only run when the Java version is 1.4, and add a note to the round method javadoc and the release notes stating that the round method may not work properly in all cases involving DST rollovers in previous JVMs, with this case as an example. Thoughs? -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2
Gary, I have a fix for that problem. I'll go ahead and put up a corrected source distribution with the fix and without the DateUtilsTest correction so you can try 1.3.1. On 5/24/05, Gary Gregory [EMAIL PROTECTED] wrote: I'd like to check 1.3.1 but... running ant clean build-dist-2.1 test from src-zip does not make it past text tests: test.text: [echo] Running text package tests ... [java] Class not found org.apache.commons.lang.text.TextTestSuite BUILD FAILED C:\temp\commons-lang-2.1-RC6\build.xml:206: Java returned: 1 Which should not be run in the 1st place... (Ant 1.6.4 and Java 1.4.2_08) Gary -Original Message- From: Steven Caswell [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 24, 2005 5:39 PM To: Jakarta Commons Developers List Subject: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2 All, I have discovered a group of tests in the DateUtils test case that fails under 1.2.2 but not under 1.4.2. They are testing the DateUtils round method when rounding a date in the MET timezone across the start and end of DST. If I remember correctly, this was in response to a user bug report. In particular the test is at line 472 of the testRound method in DataUtilsTest.java. The test passes fine when run under 1.4.2 but fails under 1.2.2. I don't have a 1.3 installation available so I don't know if it passes or fails under 1.3. I propose that we put a condition around the test so that is only run when the Java version is 1.4, and add a note to the round method javadoc and the release notes stating that the round method may not work properly in all cases involving DST rollovers in previous JVMs, with this case as an example. Thoughs? -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2
Gary, I put up the revised source distribution in http://www.apache.org/~stevencaswell/commons-lang-2.1 I named them commons-lang-2.1-RC6a-src.* so you could easily tell they are modified. I was just too lazy to change it to RC7 for a minor non-code fix, and since there will probably be an RC7 with the date utils test change. Thanks for your patience and thanks for testing these things. On 5/24/05, Steven Caswell [EMAIL PROTECTED] wrote: Gary, I have a fix for that problem. I'll go ahead and put up a corrected source distribution with the fix and without the DateUtilsTest correction so you can try 1.3.1. On 5/24/05, Gary Gregory [EMAIL PROTECTED] wrote: I'd like to check 1.3.1 but... running ant clean build-dist-2.1 test from src-zip does not make it past text tests: test.text: [echo] Running text package tests ... [java] Class not found org.apache.commons.lang.text.TextTestSuite BUILD FAILED C:\temp\commons-lang-2.1-RC6\build.xml:206: Java returned: 1 Which should not be run in the 1st place... (Ant 1.6.4 and Java 1.4.2_08) Gary -Original Message- From: Steven Caswell [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 24, 2005 5:39 PM To: Jakarta Commons Developers List Subject: [lang] DateUtils test fails under 1.2.2 and not under 1.4.2 All, I have discovered a group of tests in the DateUtils test case that fails under 1.2.2 but not under 1.4.2. They are testing the DateUtils round method when rounding a date in the MET timezone across the start and end of DST. If I remember correctly, this was in response to a user bug report. In particular the test is at line 472 of the testRound method in DataUtilsTest.java. The test passes fine when run under 1.4.2 but fails under 1.2.2. I don't have a 1.3 installation available so I don't know if it passes or fails under 1.3. I propose that we put a condition around the test so that is only run when the Java version is 1.4, and add a note to the round method javadoc and the release notes stating that the round method may not work properly in all cases involving DST rollovers in previous JVMs, with this case as an example. Thoughs? -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] VOTE 2.1 release (new vote based on RC6)
org.apache.commons.lang.exception... [javadoc] Loading source files for package org.apache.commons.lang.math... [javadoc] Loading source files for package org.apache.commons.lang.mutable... [javadoc] Loading source files for package org.apache.commons.lang.time... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.4.2_08 [javadoc] Building tree for all the packages and classes... [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... dist: [copy] Copying 1 file to C:\temp\commons-lang-2.1-RC6\dist [copy] Copying 1 file to C:\temp\commons-lang-2.1-RC6\dist BUILD FAILED C:\temp\commons-lang-2.1-RC6\build.xml:120: The following error occurred while executing this line: C:\temp\commons-lang-2.1-RC6\build.xml:115: Warning: Could not find file C:\temp\commons-lang-2.1-RC6\RELEASE-NOTES.txt to copy. Total time: 54 seconds C:\temp\commons-lang-2.1-RC6 -Original Message- From: Steven Caswell [mailto:[EMAIL PROTECTED] Sent: Saturday, May 21, 2005 7:39 PM To: Jakarta Commons Developers List Subject: [lang] VOTE 2.1 release (new vote based on RC6) RC6 is available at http://www.apache.org/~stevencaswell/commons-lang-2.1http://www.apache. org/%7Estevencaswell/commons-lang-2.1 Fixed is the javadoc generation to include the overview and package notes (was being omitted due to a bug in the maven javadoc plugin). Also fixed the manifest version. As with previous RCs, a test of the distribution against Java 1.2 would be greatly appreciated. Here is the vote for making this RC the 2.1 release: [ ] +1 [ ] -1 -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] VOTE 2.1 release (new vote based on RC6)
No, my mistake, I should have looked closer. There is a reference to that
version in the javadoc generation output. So I should ask, any progress on
the 1.2.2 issue? I'm trying to imagine how the source would affect that and
I can't see how it would, at least not at the level you are seeing the
errors. Maybe a cross-pointing between 1.2 and 1.4?
On 5/23/05, Gary Gregory [EMAIL PROTECTED] wrote:
Sorry, I should have been clearer. If by earlier problem you mean the
hanging 1.2.2 build, it is not solved. The build below with the missing
RELEASE-NOTES.txt was run with Sun Java 1.4.2_08.
Gary
--
*From:* Steven Caswell [mailto:[EMAIL PROTECTED]
*Sent:* Monday, May 23, 2005 11:14 AM
*To:* Gary Gregory
*Cc:* Jakarta Commons Developers List
*Subject:* Re: [lang] VOTE 2.1 release (new vote based on RC6)
That seems odd since I used maven to gen the sources. Will take a look.
Looks like your earlier problem is fixed.
On 5/23/05, *Gary Gregory* [EMAIL PROTECTED] wrote:
Hello:
RELEASE-NOTES.txt is missing from:
http://people.apache.org/~stevencaswell/commons-lang-2.1/distributions/chttp://people.apache.org/%7Estevencaswell/commons-lang-2.1/distributions/c
ommons-lang-2.1-RC6-src.zip
Unzipping the above and running:
ant clean dist-build-2.1
gives the error:
Buildfile: build.xml
clean:
[delete] Deleting directory C:\temp\commons-lang-2.1-RC6\target
dist-build-2.1 :
clean:
init:
[echo] commons-lang 2.1-RC6
prepare:
[mkdir] Created dir: C:\temp\commons-lang-2.1-RC6\target
[mkdir] Created dir: C:\temp\commons-lang-2.1-RC6\target\classes
[mkdir] Created dir: C:\temp\commons-lang-2.1-RC6\target\conf
[mkdir] Created dir: C:\temp\commons-lang-2.1-RC6\target\tests
static:
[copy] Copying 1 file to C:\temp\commons-lang-2.1-RC6\target\conf
compile:
[javac] Compiling 70 source files to
C:\temp\commons-lang-2.1-RC6\target\classes
[javac]
C:\temp\commons-lang-2.1-RC6\src\java\org\apache\commons\lang\enum\EnumU
tils.java:53: warning: org.apache.commons.lang.enum.Enum in
org.apache.commons.lang.en
um has been deprecated
[javac] public static Enum getEnum(Class enumClass, String name)
{
[javac] ^
[javac]
C:\temp\commons-lang-2.1-RC6\src\java\org\apache\commons\lang\enum\Value
dEnum.java:137: warning: org.apache.commons.lang.enum.Enum in
org.apache.commons.lang.
enum has been deprecated
[javac] protected static Enum getEnum(Class enumClass, int
value) {
[javac] ^
[javac]
C:\temp\commons-lang-2.1-RC6\src\java\org\apache\commons\lang\enum\EnumU
tils.java:65: warning: org.apache.commons.lang.enum.ValuedEnum in
org.apache.commons.l
ang.enum has been deprecated
[javac] public static ValuedEnum getEnum(Class enumClass, int
value) {
[javac] ^
[javac]
C:\temp\commons-lang-2.1-RC6\src\java\org\apache\commons\lang\enum\Enum.
java:335: warning: org.apache.commons.lang.enum.ValuedEnum in
org.apache.commons.lang.
enum has been deprecated
[javac] while (cls != null cls != Enum.class cls !=
ValuedEnum.class) {
[javac] ^
[javac]
C:\temp\commons-lang-2.1-RC6\src\java\org\apache\commons\lang\enum\Enum.
java:484: warning: org.apache.commons.lang.enum.ValuedEnum in
org.apache.commons.lang.
enum has been deprecated
[javac] while (cls != null cls != Enum.class cls !=
ValuedEnum.class) {
[javac] ^
[javac]
C:\temp\commons-lang-2.1-RC6\src\java\org\apache\commons\lang\enum\EnumU
tils.java:54: warning: org.apache.commons.lang.enum.Enum in
org.apache.commons.lang.en
um has been deprecated
[javac] return Enum.getEnum(enumClass, name);
[javac] ^
[javac]
C:\temp\commons-lang-2.1-RC6\src\java\org\apache\commons\lang\enum\EnumU
tils.java:66: warning: org.apache.commons.lang.enum.ValuedEnum in
org.apache.commons.l
ang.enum has been deprecated
[javac] return (ValuedEnum) ValuedEnum.getEnum(enumClass,
value);
[javac] ^
[javac]
C:\temp\commons-lang-2.1-RC6\src\java\org\apache\commons\lang\enum\EnumU
tils.java:66: warning: org.apache.commons.lang.enum.ValuedEnum in
org.apache.commons.l
ang.enum has been deprecated
[javac] return (ValuedEnum) ValuedEnum.getEnum(enumClass,
value);
[javac] ^
[javac]
C:\temp\commons-lang-2.1-RC6\src\java\org\apache\commons\lang\enum\EnumU
tils.java:83: warning: org.apache.commons.lang.enum.Enum in
org.apache.commons.lang.en
um has been deprecated
[javac] return Enum.getEnumMap(enumClass);
[javac] ^
[javac]
C:\temp\commons-lang-2.1-RC6\src\java\org\apache\commons\lang\enum\EnumU
tils.java:103: warning: org.apache.commons.lang.enum.Enum in
org.apache.commons.lang.e
num has been deprecated
[javac] return Enum.getEnumList(enumClass);
[javac] ^
[javac]
C:\temp\commons-lang-2.1-RC6\src\java\org\apache\commons\lang\enum\EnumU
tils.java :123: warning: org.apache.commons.lang.enum.Enum in
org.apache.commons.lang.e
num has been deprecated
[javac] return Enum.getEnumList(enumClass).iterator();
[javac] ^
[javac]
C:\temp
[lang] Should RELEASE-NOTES.txt be copied into the source distribution?
All, Gary ran across something that I hadn't run across due to how I was creating the various distributions, and I'd like to ask for a concensus on how to handle this. Here is the scenario: 1. Download the source distribution (i.e., commons-lang-2.1-whatever.zip) 2. Attempt to build a binary distribution using the ant script: $ ant build.xml dist-build-2.1 This fails because the source distribution (build with maven) does not include the release notes files RELEASE-NOTES.txt, which the ant build assumes is available and tries to put into the binary distribution. The obvious solution is to include RELEASE-NOTES.txt in the source distribution, but I wanted make sure there wasn't anyone opposed to doing so.I'm going to go ahead and rebuild the RC6 source distribution with this additional file, and if there is any objection we can discuss. TIA -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] VOTE 2.1 release (new vote based on RC6)
Gary,
I suspect building against 1.4.2 and running against 1.2.2 will not work due
to changes in the Java API. The RC binary distribution is in fact build with
1.2.2, so it may be sufficient just to run the downloaded RC6 against your
1.2.2 without building from scratch.
On 5/23/05, Gary Gregory [EMAIL PROTECTED] wrote:
As another data point, building with Java 1.3.1_14 ends with the same
error below as with 1.4.2_08:
BUILD FAILED
C:\temp\commons-lang-2.1-RC6\build.xml:120: The following error occurred
while executing this line:
C:\temp\commons-lang-2.1-RC6\build.xml:115: Warning: Could not find file
C:\temp\commons-lang-2.1-RC6\RELEASE-NOTES.txt to copy.
So I am thinking that there is a bug in Ant 1.6.4 when used with Sun Java
1.2.2_017.
If you can fix the missing file problem I can do a local build with 1.3.1or
1.4.2 but run the test target with 1.2.2.
Gary
--
*From:* Steven Caswell [mailto:[EMAIL PROTECTED]
*Sent:* Monday, May 23, 2005 11:26 AM
*To:* Gary Gregory
*Cc:* Jakarta Commons Developers List
*Subject:* Re: [lang] VOTE 2.1 release (new vote based on RC6)
No, my mistake, I should have looked closer. There is a reference to that
version in the javadoc generation output. So I should ask, any progress on
the 1.2.2 issue? I'm trying to imagine how the source would affect that
and I can't see how it would, at least not at the level you are seeing the
errors. Maybe a cross-pointing between 1.2 and 1.4?
On 5/23/05, *Gary Gregory* [EMAIL PROTECTED] wrote:
Sorry, I should have been clearer. If by earlier problem you mean the
hanging 1.2.2 build, it is not solved. The build below with the missing
RELEASE-NOTES.txt was run with Sun Java 1.4.2_08.
Gary
--
*From:* Steven Caswell [mailto: [EMAIL PROTECTED]
*Sent:* Monday, May 23, 2005 11:14 AM
*To:* Gary Gregory
*Cc:* Jakarta Commons Developers List
*Subject:* Re: [lang] VOTE 2.1 release (new vote based on RC6)
That seems odd since I used maven to gen the sources. Will take a look.
Looks like your earlier problem is fixed.
On 5/23/05, *Gary Gregory* [EMAIL PROTECTED] wrote:
Hello:
RELEASE-NOTES.txt is missing from:
http://people.apache.org/~stevencaswell/commons-lang-2.1/distributions/c
http://people.apache.org/%7Estevencaswell/commons-lang-2.1/distributions/c
ommons-lang-2.1-RC6-src.zip
Unzipping the above and running:
ant clean dist-build-2.1
gives the error:
Buildfile: build.xml
clean:
[delete] Deleting directory C:\temp\commons-lang-2.1-RC6\target
dist-build-2.1 :
clean:
init:
[echo] commons-lang 2.1-RC6
prepare:
[mkdir] Created dir: C:\temp\commons-lang-2.1-RC6\target
[mkdir] Created dir: C:\temp\commons-lang-2.1-RC6\target\classes
[mkdir] Created dir: C:\temp\commons-lang-2.1-RC6\target\conf
[mkdir] Created dir: C:\temp\commons-lang-2.1-RC6\target\tests
static:
[copy] Copying 1 file to C:\temp\commons-lang-2.1-RC6\target\conf
compile:
[javac] Compiling 70 source files to
C:\temp\commons-lang-2.1-RC6\target\classes
[javac]
C:\temp\commons-lang-2.1-RC6\src\java\org\apache\commons\lang\enum\EnumU
tils.java:53: warning: org.apache.commons.lang.enum.Enum in
org.apache.commons.lang.en
um has been deprecated
[javac] public static Enum getEnum(Class enumClass, String name)
{
[javac] ^
[javac]
C:\temp\commons-lang-2.1-RC6\src\java\org\apache\commons\lang\enum\Value
dEnum.java:137: warning: org.apache.commons.lang.enum.Enum in
org.apache.commons.lang.
enum has been deprecated
[javac] protected static Enum getEnum(Class enumClass, int
value) {
[javac] ^
[javac]
C:\temp\commons-lang-2.1-RC6\src\java\org\apache\commons\lang\enum\EnumU
tils.java:65: warning: org.apache.commons.lang.enum.ValuedEnum in
org.apache.commons.l
ang.enum has been deprecated
[javac] public static ValuedEnum getEnum(Class enumClass, int
value) {
[javac] ^
[javac]
C:\temp\commons-lang-2.1-RC6\src\java\org\apache\commons\lang\enum\Enum.
java:335: warning: org.apache.commons.lang.enum.ValuedEnum in
org.apache.commons.lang.
enum has been deprecated
[javac] while (cls != null cls != Enum.class cls !=
ValuedEnum.class) {
[javac] ^
[javac]
C:\temp\commons-lang-2.1-RC6\src\java\org\apache\commons\lang\enum\Enum.
java:484: warning: org.apache.commons.lang.enum.ValuedEnum in
org.apache.commons.lang.
enum has been deprecated
[javac] while (cls != null cls != Enum.class cls !=
ValuedEnum.class) {
[javac] ^
[javac]
C:\temp\commons-lang-2.1-RC6\src\java\org\apache\commons\lang\enum\EnumU
tils.java:54: warning: org.apache.commons.lang.enum.Enum in
org.apache.commons.lang.en
um has been deprecated
[javac] return Enum.getEnum(enumClass, name);
[javac] ^
[javac]
C:\temp\commons-lang-2.1-RC6\src\java\org\apache\commons\lang\enum\EnumU
tils.java:66: warning: org.apache.commons.lang.enum.ValuedEnum
Fwd: [lang] Should RELEASE-NOTES.txt be copied into the source distribution?
Actually, never mind. I should have looked at the maven.xml first. We are in fact trying to copy the release notes file, but the maven.xml has RELEASE-NOTES.html and the file is RELEASE-NOTES.txt. I'll make the fix. -- Forwarded message -- From: Steven Caswell [EMAIL PROTECTED] Date: May 23, 2005 6:11 PM Subject: [lang] Should RELEASE-NOTES.txt be copied into the source distribution? To: Jakarta Commons Developers List commons-dev@jakarta.apache.org All, Gary ran across something that I hadn't run across due to how I was creating the various distributions, and I'd like to ask for a concensus on how to handle this. Here is the scenario: 1. Download the source distribution (i.e., commons-lang-2.1-whatever.zip) 2. Attempt to build a binary distribution using the ant script: $ ant build.xml dist-build-2.1 This fails because the source distribution (build with maven) does not include the release notes files RELEASE-NOTES.txt, which the ant build assumes is available and tries to put into the binary distribution. The obvious solution is to include RELEASE-NOTES.txt in the source distribution, but I wanted make sure there wasn't anyone opposed to doing so.I'm going to go ahead and rebuild the RC6 source distribution with this additional file, and if there is any objection we can discuss. TIA -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] VOTE 2.1 release (new vote based on RC6)
All,
I have replaced the RC6 source distributions with new ones containing the
RELEASE-NOTES.txt file. Thanks to Gary for finding the omission.
On 5/23/05, Steven Caswell [EMAIL PROTECTED] wrote:
Gary,
I suspect building against 1.4.2 and running against 1.2.2 will not work
due to changes in the Java API. The RC binary distribution is in fact build
with 1.2.2, so it may be sufficient just to run the downloaded RC6 against
your 1.2.2 without building from scratch.
On 5/23/05, Gary Gregory [EMAIL PROTECTED] wrote:
As another data point, building with Java 1.3.1_14 ends with the same
error below as with 1.4.2_08:
BUILD FAILED
C:\temp\commons-lang-2.1-RC6\build.xml:120: The following error occurred
while executing this line:
C:\temp\commons-lang-2.1-RC6\build.xml:115: Warning: Could not find file
C:\temp\commons-lang-2.1-RC6\RELEASE-NOTES.txt to copy.
So I am thinking that there is a bug in Ant 1.6.4 when used with Sun
Java 1.2.2_017.
If you can fix the missing file problem I can do a local build with
1.3.1 or 1.4.2 but run the test target with 1.2.2.
Gary
--
*From:* Steven Caswell [mailto: [EMAIL PROTECTED]
*Sent:* Monday, May 23, 2005 11:26 AM
*To:* Gary Gregory
*Cc:* Jakarta Commons Developers List
*Subject:* Re: [lang] VOTE 2.1 release (new vote based on RC6)
No, my mistake, I should have looked closer. There is a reference to
that version in the javadoc generation output. So I should ask, any
progress
on the 1.2.2 issue? I'm trying to imagine how the source would affect
that and I can't see how it would, at least not at the level you are seeing
the errors. Maybe a cross-pointing between 1.2 and 1.4?
On 5/23/05, *Gary Gregory* [EMAIL PROTECTED] wrote:
Sorry, I should have been clearer. If by earlier problem you mean the
hanging 1.2.2 build, it is not solved. The build below with the missing
RELEASE-NOTES.txt was run with Sun Java 1.4.2_08.
Gary
--
*From:* Steven Caswell [mailto: [EMAIL PROTECTED]
*Sent:* Monday, May 23, 2005 11:14 AM
*To:* Gary Gregory
*Cc:* Jakarta Commons Developers List
*Subject:* Re: [lang] VOTE 2.1 release (new vote based on RC6)
That seems odd since I used maven to gen the sources. Will take a look.
Looks like your earlier problem is fixed.
On 5/23/05, *Gary Gregory* [EMAIL PROTECTED] wrote:
Hello:
RELEASE-NOTES.txt is missing from:
http://people.apache.org/~stevencaswell/commons-lang-2.1/distributions/c
http://people.apache.org/%7Estevencaswell/commons-lang-2.1/distributions/c
ommons-lang-2.1-RC6-src.zip
Unzipping the above and running:
ant clean dist-build-2.1
gives the error:
Buildfile: build.xml
clean:
[delete] Deleting directory C:\temp\commons-lang-2.1-RC6\target
dist-build-2.1 :
clean:
init:
[echo] commons-lang 2.1-RC6
prepare:
[mkdir] Created dir: C:\temp\commons-lang-2.1-RC6\target
[mkdir] Created dir: C:\temp\commons-lang-2.1-RC6\target\classes
[mkdir] Created dir: C:\temp\commons-lang-2.1-RC6\target\conf
[mkdir] Created dir: C:\temp\commons-lang-2.1-RC6\target\tests
static:
[copy] Copying 1 file to C:\temp\commons-lang-2.1-RC6\target\conf
compile:
[javac] Compiling 70 source files to
C:\temp\commons-lang-2.1-RC6\target\classes
[javac]
C:\temp\commons-lang-2.1-RC6\src\java\org\apache\commons\lang\enum\EnumU
tils.java:53: warning: org.apache.commons.lang.enum.Enum in
org.apache.commons.lang.en
um has been deprecated
[javac] public static Enum getEnum(Class enumClass, String name)
{
[javac] ^
[javac]
C:\temp\commons-lang-2.1-RC6\src\java\org\apache\commons\lang\enum\Value
dEnum.java:137: warning: org.apache.commons.lang.enum.Enum in
org.apache.commons.lang.
enum has been deprecated
[javac] protected static Enum getEnum(Class enumClass, int
value) {
[javac] ^
[javac]
C:\temp\commons-lang-2.1-RC6\src\java\org\apache\commons\lang\enum\EnumU
tils.java:65: warning: org.apache.commons.lang.enum.ValuedEnum in
org.apache.commons.l
ang.enum has been deprecated
[javac] public static ValuedEnum getEnum(Class enumClass, int
value) {
[javac] ^
[javac]
C:\temp\commons-lang-2.1-RC6\src\java\org\apache\commons\lang\enum\Enum.
java:335: warning: org.apache.commons.lang.enum.ValuedEnum in
org.apache.commons.lang.
enum has been deprecated
[javac] while (cls != null cls != Enum.class cls !=
ValuedEnum.class) {
[javac] ^
[javac]
C:\temp\commons-lang-2.1-RC6\src\java\org\apache\commons\lang\enum\Enum.
java:484: warning: org.apache.commons.lang.enum.ValuedEnum in
org.apache.commons.lang.
enum has been deprecated
[javac] while (cls != null cls != Enum.class cls !=
ValuedEnum.class) {
[javac] ^
[javac]
C:\temp\commons-lang-2.1-RC6\src\java\org\apache\commons
[lang] VOTE 2.1 release (new vote based on RC6)
RC6 is available at http://www.apache.org/~stevencaswell/commons-lang-2.1http://www.apache.org/%7Estevencaswell/commons-lang-2.1 Fixed is the javadoc generation to include the overview and package notes (was being omitted due to a bug in the maven javadoc plugin). Also fixed the manifest version. As with previous RCs, a test of the distribution against Java 1.2 would be greatly appreciated. Here is the vote for making this RC the 2.1 release: [ ] +1 [ ] -1 -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] VOTE 2.1 release (new vote based on RC5)
All,
The problem with generating the javadocs is indeed a bug in the maven
javadoc plugin:
http://marc.theaimsgroup.com/?l=turbine-maven-userm=111654720406621w=2 and
http://jira.codehaus.org/browse/MPJAVADOC-59
I'll pull down the fix this weekend and generate a new release candidate.
Gary, I suspect you hadn't updated your local copy of project.xml when you
got your clean copy of the javadoc since it was the recent addition of the
source modification that seems to cause the problem. That is the only reason
I can think of why yours worked and mine didn't.
On 5/19/05, Gary Gregory [EMAIL PROTECTED] wrote:
Steven:
If it helps, here is my Maven info:
C:\cvs-store\transidiom\deve\Java\Buildmaven --info | find javadoc
maven-javadoc-plugin-1.7
and:
C:\cvs-store\transidiom\deve\Java\Buildmaven --info
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0.2
# BEGIN: Which report
Which.version=Which.java:($Revision: 1.2 $) WhichJar.java:($Revision:
1.2 $)
java.version=1.4.2_08
file.encoding=Cp1252
java.ext.dirs=c:\java\sun\1.4.2_08\jre\lib\ext
java.class.path=C:\Program Files\Apache Software Foundation\Maven
1.0.2\lib\forehead-1.0-beta-5.jar
os.name=Windows XP
java.vendor=Sun Microsystems Inc.
sun.boot.class.path=C:\Program Files\Apache Software Foundation\Maven
1.0.2\lib\endorsed\xerces-2.4.0.jar;C:\Program Files\Apache Software
Foundation\Maven 1.0.2\lib\endo
rsed\xml-apis-1.0.b2.jar;c:\java\sun\1.4.2_08\jre\lib\rt.jar;c:\java\sun
\1.4.2_08\jre\lib\i18n.jar;c:\java\sun\1.4.2_08\jre\lib\sunrsasign.jar;c
:\java\sun\1.4.2_08\jre\li
b\jsse.jar;c:\java\sun\1.4.2_08\jre\lib\jce.jar;c:\java\sun\1.4.2_08\jre
\lib\charsets.jar;c:\java\sun\1.4.2_08\jre\classes
java.runtime.name=Java(TM) 2 Runtime Environment, Standard Edition
# END: Which report
Installed plugins:
maven-abbot-plugin-1.1
maven-announcement-plugin-1.3
maven-ant-plugin-1.8.1
maven-antlr-plugin-1.2.1
maven-appserver-plugin-2.0
maven-artifact-plugin-1.4.1
maven-ashkelon-plugin-1.2
maven-aspectj-plugin-3.2
maven-aspectwerkz-plugin-1.2
maven-caller-plugin-1.1
maven-castor-plugin-1.2
maven-changelog-plugin-1.7.1
maven-changes-plugin-1.5.1
maven-checkstyle-plugin-2.5
maven-clean-plugin-1.3
maven-clover-plugin-1.6
maven-console-plugin-1.1
maven-cruisecontrol-plugin-1.6
maven-dashboard-plugin-1.6
maven-developer-activity-plugin-1.5.1
maven-dist-plugin-1.6.1
maven-docbook-plugin-1.2
maven-ear-plugin-1.6
maven-eclipse-plugin-1.9
maven-ejb-plugin-1.5
maven-faq-plugin-1.4
maven-file-activity-plugin-1.5.1
maven-genapp-plugin-2.2
maven-gump-plugin-1.4
maven-hibernate-plugin-1.2
maven-html2xdoc-plugin-1.3.1
maven-idea-plugin-1.5
maven-j2ee-plugin-1.5.1
maven-jalopy-plugin-1.3.1
maven-jar-plugin-1.6.1
maven-java-plugin-1.5
maven-javacc-plugin-1.1
maven-javadoc-plugin-1.7
maven-jboss-plugin-1.5
maven-jbuilder-plugin-1.5
maven-jcoverage-plugin-1.0.9
maven-jdee-plugin-1.1
maven-jdepend-plugin-1.5
maven-jdeveloper-plugin-1.4
maven-jdiff-plugin-1.4
maven-jellydoc-plugin-1.3.1
maven-jetty-plugin-1.1
maven-jira-plugin-1.1.2
maven-jnlp-plugin-1.4.1
maven-junit-doclet-plugin-1.2
maven-junit-report-plugin-1.5
maven-jxr-plugin-1.4.2
maven-latex-plugin-1.4.1
maven-latka-plugin-1.4.1
maven-license-plugin-1.2
maven-linkcheck-plugin-1.3.4
maven-multichanges-plugin-1.1
maven-multiproject-plugin-1.3.1
maven-native-plugin-1.1
maven-nsis-plugin-1.1
maven-pdf-plugin-2.2.1
maven-plugin-plugin-1.5.2
maven-pmd-plugin-1.6
maven-pom-plugin-1.4.1
maven-rar-plugin-1.0
maven-release-plugin-1.4.1
maven-repository-plugin-1.2
maven-scm-plugin-1.4.1
maven-shell-plugin-1.1
maven-simian-plugin-1.4
maven-site-plugin-1.5.2
maven-struts-plugin-1.3
maven-tasklist-plugin-2.3
maven-test-plugin-1.6.2
maven-tjdo-plugin-1.0.0
maven-uberjar-plugin-1.2
maven-vdoclet-plugin-1.2
maven-war-plugin-1.6.1
maven-webserver-plugin-2.0
maven-wizard-plugin-1.1
maven-xdoc-plugin-1.8
Home Build properties:
{junit.jar=C:\cvs-store\thirdparty\JUnit\3.8.1\junit.jar}
Gary
-Original Message-
From: Steven Caswell [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 18, 2005 2:38 PM
To: Gary Gregory
Cc: Jakarta Commons Developers List
Subject: Re: [lang] VOTE 2.1 release (new vote based on RC5)
I think I found the problem. I need to do some more investigation, but
it
looks like an issue with the version of the maven javadoc plugin I am
using.
It looks like the maven-javadoc-plugin version 1.7 copies the source
files
to a separate area when there are source modifications in project.xml,
and
uses this area to remove the source modifications and then builds the
javadoc from the remaining source. Apparently it doesn't drag the .html
files along with the .java files, so the javadoc is void of overview and
package contents.
Since I added the source modification in the latest project.xml, you may
not
have
Re: [lang] VOTE 2.1 release (new vote based on RC5)
Gary, No, unfortunately, no progress and I apologize for the silence. I've lost my DSL connection at home (long boring story) and haven't been able to devote any time to the issue. Hopefully I'll get the DSL resolved today and will have some time to work on this tonight and tomorrow. If anyone else wants to take a shot at it that would be fine and if not I'll be back on it in the next couple of days. Cheers. On 5/17/05, Gary Gregory [EMAIL PROTECTED] wrote: Hi Steven All: Any progress/ideas on the Javadoc problem? Thanks, Gary -- *From:* Steven Caswell [mailto:[EMAIL PROTECTED] *Sent:* Tuesday, May 10, 2005 11:16 AM *To:* Gary Gregory *Cc:* Jakarta Commons Developers List *Subject:* Re: [lang] VOTE 2.1 release (new vote based on RC5) Gary, Offhand I haven't a clue. I'll have to poke around and see if I can figure it out. The docs at http://people.apache.org/~stevencaswell/commons-lang-2.1/docs/apidocs/http://people.apache.org/%7Estevencaswell/commons-lang-2.1/docs/apidocs/came from maven site:generate with Maven 1.0.2, so I'm a bit confused as to why you get a different result. A couple of questions. What is the JDK you are running the maven against? and what op sys are you running it on. Not sure if either have any affect, but it might be a place to start looking. My JDK is 1.4.2_08 and my op sys is Windows XP. On 5/10/05, *Gary Gregory* [EMAIL PROTECTED] wrote: Steven: When I look at the Javadocs here: http://people.apache.org/~stevencaswell/commons-lang-2.1/docs/apidocs/inhttp://people.apache.org/%7Estevencaswell/commons-lang-2.1/docs/apidocs/in dex.html None of the comments from the package.html files show up in the package descriptions in the table in the frame: http://people.apache.org/~stevencaswell/commons-lang-2.1/docs/apidocs/ov http://people.apache.org/%7Estevencaswell/commons-lang-2.1/docs/apidocs/ov erview-summary.html When I run a maven site:generate locally, I get the proper comments. I am using Maven 1.0.2. How can this be? Gary -Original Message- From: Steven Caswell [mailto: [EMAIL PROTECTED] Sent: Wednesday, May 04, 2005 6:59 PM To: Jakarta Commons Developers List Subject: [lang] VOTE 2.1 release (new vote based on RC5) RC5 is available at http://www.apache.org/~stevencaswell/commons-lang-2.1http://www.apache.org/%7Estevencaswell/commons-lang-2.1 The significant change is the exclusion of the o.c.l.text package and associated javadocs, clover results, jdiff, clirr. I also found and corrected the maven xdoc problem that caused the extra space between anchors and punctuation. Hopefully we are ready to go with this one, so here is the vote: [ ] +1 [ ] -1 -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] VOTE 2.1 release (new vote based on RC5)
I think I found the problem. I need to do some more investigation, but it looks like an issue with the version of the maven javadoc plugin I am using. It looks like the maven-javadoc-plugin version 1.7 copies the source files to a separate area when there are source modifications in project.xml, and uses this area to remove the source modifications and then builds the javadoc from the remaining source. Apparently it doesn't drag the .html files along with the .java files, so the javadoc is void of overview and package contents. Since I added the source modification in the latest project.xml, you may not have refreshed your local copy, so you would see the javadoc built without the source modifications, which I think is done on the src folder in place. Or you might be using an older version of the javadoc plugin. Now on to the maven users list. On 5/10/05, Gary Gregory [EMAIL PROTECTED] wrote: I'm a bit confused as to why you get a different result. Indeed, it seems that your site is missing some information (the pkg desc), while I get the full Javadoc generated. Weird. Gary -- *From:* Steven Caswell [mailto:[EMAIL PROTECTED] *Sent:* Tuesday, May 10, 2005 11:16 AM *To:* Gary Gregory *Cc:* Jakarta Commons Developers List *Subject:* Re: [lang] VOTE 2.1 release (new vote based on RC5) Gary, Offhand I haven't a clue. I'll have to poke around and see if I can figure it out. The docs at http://people.apache.org/~stevencaswell/commons-lang-2.1/docs/apidocs/http://people.apache.org/%7Estevencaswell/commons-lang-2.1/docs/apidocs/came from maven site:generate with Maven 1.0.2, so I'm a bit confused as to why you get a different result. A couple of questions. What is the JDK you are running the maven against? and what op sys are you running it on. Not sure if either have any affect, but it might be a place to start looking. My JDK is 1.4.2_08 and my op sys is Windows XP. On 5/10/05, *Gary Gregory* [EMAIL PROTECTED] wrote: Steven: When I look at the Javadocs here: http://people.apache.org/~stevencaswell/commons-lang-2.1/docs/apidocs/inhttp://people.apache.org/%7Estevencaswell/commons-lang-2.1/docs/apidocs/in dex.html None of the comments from the package.html files show up in the package descriptions in the table in the frame: http://people.apache.org/~stevencaswell/commons-lang-2.1/docs/apidocs/ov http://people.apache.org/%7Estevencaswell/commons-lang-2.1/docs/apidocs/ov erview-summary.html When I run a maven site:generate locally, I get the proper comments. I am using Maven 1.0.2. How can this be? Gary -Original Message- From: Steven Caswell [mailto: [EMAIL PROTECTED] Sent: Wednesday, May 04, 2005 6:59 PM To: Jakarta Commons Developers List Subject: [lang] VOTE 2.1 release (new vote based on RC5) RC5 is available at http://www.apache.org/~stevencaswell/commons-lang-2.1http://www.apache.org/%7Estevencaswell/commons-lang-2.1 The significant change is the exclusion of the o.c.l.text package and associated javadocs, clover results, jdiff, clirr. I also found and corrected the maven xdoc problem that caused the extra space between anchors and punctuation. Hopefully we are ready to go with this one, so here is the vote: [ ] +1 [ ] -1 -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] VOTE 2.1 release (new vote based on RC5)
Gary, Offhand I haven't a clue. I'll have to poke around and see if I can figure it out. The docs at http://people.apache.org/~stevencaswell/commons-lang-2.1/docs/apidocs/ came from maven site:generate with Maven 1.0.2, so I'm a bit confused as to why you get a different result. A couple of questions. What is the JDK you are running the maven against? and what op sys are you running it on. Not sure if either have any affect, but it might be a place to start looking. My JDK is 1.4.2_08 and my op sys is Windows XP. On 5/10/05, Gary Gregory [EMAIL PROTECTED] wrote: Steven: When I look at the Javadocs here: http://people.apache.org/~stevencaswell/commons-lang-2.1/docs/apidocs/in dex.html None of the comments from the package.html files show up in the package descriptions in the table in the frame: http://people.apache.org/~stevencaswell/commons-lang-2.1/docs/apidocs/ov erview-summary.html When I run a maven site:generate locally, I get the proper comments. I am using Maven 1.0.2. How can this be? Gary -Original Message- From: Steven Caswell [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 04, 2005 6:59 PM To: Jakarta Commons Developers List Subject: [lang] VOTE 2.1 release (new vote based on RC5) RC5 is available at http://www.apache.org/~stevencaswell/commons-lang-2.1 The significant change is the exclusion of the o.c.l.text package and associated javadocs, clover results, jdiff, clirr. I also found and corrected the maven xdoc problem that caused the extra space between anchors and punctuation. Hopefully we are ready to go with this one, so here is the vote: [ ] +1 [ ] -1 -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] VOTE 2.1 release (new vote based on RC5)
The method in question is deprecated. I don't know a lot about how JDiff works, could it be marking it as removed because it is deprecaed? On 5/6/05, Henri Yandell [EMAIL PROTECTED] wrote: Still seeing a Removed method in JDiff. ReflectionToStringBuilder.toString(Object, ToStringStyle, boolean, Class). Not noticed by Clirr though. Clirr didn't notice the MILLI and enum deprecations, but it did notice ReflectionToStringBuilder deprecations that we don't list in the release notes. Manifest inside the jar looks good. Both src zip and src tar.gz build, ant and maven. I got the following when untarring, but it's probably not important. I find tar occasionally spits out bits of info that never seem to hurt the untarring. tar -zxf commons-lang-2.1-RC5-src.tar.gz tar: A lone zero block at 6020 The only problem I have with release is whether JDiff is right about an API removal, or if it's confused and Clirr is right. Hen On 5/4/05, Steven Caswell [EMAIL PROTECTED] wrote: RC5 is available at http://www.apache.org/~stevencaswell/commons-lang-2.1 The significant change is the exclusion of the o.c.l.text package and associated javadocs, clover results, jdiff, clirr. I also found and corrected the maven xdoc problem that caused the extra space between anchors and punctuation. Hopefully we are ready to go with this one, so here is the vote: [ ] +1 [ ] -1 -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
[lang] VOTE 2.1 release (new vote based on RC5)
RC5 is available at http://www.apache.org/~stevencaswell/commons-lang-2.1 The significant change is the exclusion of the o.c.l.text package and associated javadocs, clover results, jdiff, clirr. I also found and corrected the maven xdoc problem that caused the extra space between anchors and punctuation. Hopefully we are ready to go with this one, so here is the vote: [ ] +1 [ ] -1 -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] New VOTE on lang release - About .text
I will add the exclusions when I build the next release candidate. On 5/3/05, Stephen Colebourne [EMAIL PROTECTED] wrote: The text subpackage is incomplete and is to be excluded from the release. I will get to finishing it off at some point, but was waiting until after the release. I guess it will need to be excluded from all relevant parts of ant and maven. Stephen --- Gary Gregory [EMAIL PROTECTED] wrote: Hello All: I see that the text package is included in RC4 but that it is not tested from build.xml. I've fixed that part but I also notice that the new txt package in not mentioned in RELEASE-NOTES.txt. I also recall some discussions a while back about text not being fully baked. Is the inclusion of text on purpose or is it meant to be stripped? Thanks, Gary -Original Message- From: Steven Caswell [mailto:[EMAIL PROTECTED] Sent: Sunday, May 01, 2005 3:12 PM To: Jakarta Commons Developers List Subject: [lang] New VOTE on lang release Release candidate 4 is in http://www.apache.org/~stevencaswell/commons-lang-2.1/http://www.apache .org/%7Estevencaswell/commons-lang-2.1/ RC4 contains only documentation fixes reported on RC3 (thanks to Michael Heuer). There is one minor formatting issue that causes extra spaces after some anchors, that appears to be a maven formatting issue. Again, not sure if another vote is necessary, since plenty of +1s have come in for the previous RCs, but I don't want to presume anything: [ ] +1 [ ] -1 -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
[lang] Are we ready for another release candidate?
Based on issues uncovered with RC4 (thanks to Gary and Stephen for working those), I'll be cutting another release candidate soon, probably today unless there are still issues to work on. Gary, are you satisfied with where things are, or do you want some more time? -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] New VOTE on lang release - Weird Javadoc Warnings Report
Yeah, that is what happens when there are no warnings to report. Though I don't think it has been reported yet, I'd say it could be considered a bug in the Maven plug-in. And since I wrote the plug-in, I'll take full responsibility :) On 5/2/05, Gary Gregory [EMAIL PROTECTED] wrote: Hello: The Javadoc report: http://people.apache.org/~stevencaswell/commons-lang-2.1/docs/javadoc-wa rnings-report.html is nonsensical. Could this be a Maven plug-in bug? Gary -Original Message- From: Steven Caswell [mailto:[EMAIL PROTECTED] Sent: Sunday, May 01, 2005 3:12 PM To: Jakarta Commons Developers List Subject: [lang] New VOTE on lang release Release candidate 4 is in http://www.apache.org/~stevencaswell/commons-lang-2.1/http://www.apache .org/%7Estevencaswell/commons-lang-2.1/ RC4 contains only documentation fixes reported on RC3 (thanks to Michael Heuer). There is one minor formatting issue that causes extra spaces after some anchors, that appears to be a maven formatting issue. Again, not sure if another vote is necessary, since plenty of +1s have come in for the previous RCs, but I don't want to presume anything: [ ] +1 [ ] -1 -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] New VOTE on lang release
Gary, Take a look at the developer's guide in the RC. I added some info on how to set up the Clover license since I just went through this myself. The instructions probably aren't complete, but hopefully will be enough to get you running. On 5/2/05, Gary Gregory [EMAIL PROTECTED] wrote: Hello: Clover is pretty but what a pain to set up WRT the license file. I've looked around and found a ref to getting the license file from the SVN committers repository, which I cannot locate, can someone point me to a URL please? I am a committer so I should be able to get it... Thanks, Gary -Original Message- From: Steven Caswell [mailto:[EMAIL PROTECTED] Sent: Sunday, May 01, 2005 3:12 PM To: Jakarta Commons Developers List Subject: [lang] New VOTE on lang release Release candidate 4 is in http://www.apache.org/~stevencaswell/commons-lang-2.1/http://www.apache .org/%7Estevencaswell/commons-lang-2.1/ RC4 contains only documentation fixes reported on RC3 (thanks to Michael Heuer). There is one minor formatting issue that causes extra spaces after some anchors, that appears to be a maven formatting issue. Again, not sure if another vote is necessary, since plenty of +1s have come in for the previous RCs, but I don't want to presume anything: [ ] +1 [ ] -1 -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] New VOTE on lang release
Gotcha. Sorry the write-up wasn't more verbose. I threw that in there without stopping to think about not everyone knowing what it meant. Try https://svn.apache.org/repos/private/committers/ On 5/2/05, Gary Gregory [EMAIL PROTECTED] wrote: Steven: Yes, I've found the guide [1] with the note: Obtain the license file from the committers svn repository (clover.license) Where do I go from pointing TortoiseSVN to: https://svn.apache.org/repos/asf/ ? Thanks, Gary [1] http://people.apache.org/~stevencaswell/commons-lang-2.1/docs/developerguide.htmlhttp://people.apache.org/%7Estevencaswell/commons-lang-2.1/docs/developerguide.html -- *From:* Steven Caswell [mailto:[EMAIL PROTECTED] *Sent:* Monday, May 02, 2005 3:58 PM *To:* Gary Gregory *Cc:* Jakarta Commons Developers List *Subject:* Re: [lang] New VOTE on lang release Gary, Take a look at the developer's guide in the RC. I added some info on how to set up the Clover license since I just went through this myself. The instructions probably aren't complete, but hopefully will be enough to get you running. On 5/2/05, *Gary Gregory* [EMAIL PROTECTED] wrote: Hello: Clover is pretty but what a pain to set up WRT the license file. I've looked around and found a ref to getting the license file from the SVN committers repository, which I cannot locate, can someone point me to a URL please? I am a committer so I should be able to get it... Thanks, Gary -Original Message- From: Steven Caswell [mailto:[EMAIL PROTECTED] ] Sent: Sunday, May 01, 2005 3:12 PM To: Jakarta Commons Developers List Subject: [lang] New VOTE on lang release Release candidate 4 is in http://www.apache.org/~stevencaswell/commons-lang-2.1/http://www.apache.org/%7Estevencaswell/commons-lang-2.1/ http://www.apache .org/%7Estevencaswell/commons-lang-2.1/ RC4 contains only documentation fixes reported on RC3 (thanks to Michael Heuer). There is one minor formatting issue that causes extra spaces after some anchors, that appears to be a maven formatting issue. Again, not sure if another vote is necessary, since plenty of +1s have come in for the previous RCs, but I don't want to presume anything: [ ] +1 [ ] -1 -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] New VOTE on lang release
Definitely should be in the dev guide. I'll add it. On 5/2/05, Gary Gregory [EMAIL PROTECTED] wrote: I was able to checkout from the URL, thanks. Worth a mention in the dev-guide? Gary -- *From:* Steven Caswell [mailto:[EMAIL PROTECTED] *Sent:* Monday, May 02, 2005 4:30 PM *To:* Gary Gregory *Cc:* Jakarta Commons Developers List *Subject:* Re: [lang] New VOTE on lang release Gotcha. Sorry the write-up wasn't more verbose. I threw that in there without stopping to think about not everyone knowing what it meant. Try https://svn.apache.org/repos/private/committers/ On 5/2/05, *Gary Gregory* [EMAIL PROTECTED] wrote: Steven: Yes, I've found the guide [1] with the note: Obtain the license file from the committers svn repository (clover.license) Where do I go from pointing TortoiseSVN to: https://svn.apache.org/repos/asf/ ? Thanks, Gary [1] http://people.apache.org/~stevencaswell/commons-lang-2.1/docs/developerguide.htmlhttp://people.apache.org/%7Estevencaswell/commons-lang-2.1/docs/developerguide.html -- *From:* Steven Caswell [mailto:[EMAIL PROTECTED] *Sent:* Monday, May 02, 2005 3:58 PM *To:* Gary Gregory *Cc:* Jakarta Commons Developers List *Subject:* Re: [lang] New VOTE on lang release Gary, Take a look at the developer's guide in the RC. I added some info on how to set up the Clover license since I just went through this myself. The instructions probably aren't complete, but hopefully will be enough to get you running. On 5/2/05, *Gary Gregory* [EMAIL PROTECTED] wrote: Hello: Clover is pretty but what a pain to set up WRT the license file. I've looked around and found a ref to getting the license file from the SVN committers repository, which I cannot locate, can someone point me to a URL please? I am a committer so I should be able to get it... Thanks, Gary -Original Message- From: Steven Caswell [mailto:[EMAIL PROTECTED] ] Sent: Sunday, May 01, 2005 3:12 PM To: Jakarta Commons Developers List Subject: [lang] New VOTE on lang release Release candidate 4 is in http://www.apache.org/~stevencaswell/commons-lang-2.1/http://www.apache.org/%7Estevencaswell/commons-lang-2.1/ http://www.apache .org/%7Estevencaswell/commons-lang-2.1/ RC4 contains only documentation fixes reported on RC3 (thanks to Michael Heuer). There is one minor formatting issue that causes extra spaces after some anchors, that appears to be a maven formatting issue. Again, not sure if another vote is necessary, since plenty of +1s have come in for the previous RCs, but I don't want to presume anything: [ ] +1 [ ] -1 -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] New VOTE on lang release - Codestyle warnings fixed.
No problem. Glad you checked it before we released. On 5/2/05, Gary Gregory [EMAIL PROTECTED] wrote: Steven: Sorry for not catching this sooner since I was the last committer on CharEncoding.java. I've fixed the warnings in that file described here: http://people.apache.org/~stevencaswell/commons-lang-2.1/docs/checkstyle -report.html#org/apache/commons/lang/CharEncoding.java I've also fixed the same 120 length warnings in a couple of other files. Thanks, Gary -Original Message- From: Steven Caswell [mailto:[EMAIL PROTECTED] Sent: Sunday, May 01, 2005 3:12 PM To: Jakarta Commons Developers List Subject: [lang] New VOTE on lang release Release candidate 4 is in http://www.apache.org/~stevencaswell/commons-lang-2.1/http://www.apache .org/%7Estevencaswell/commons-lang-2.1/ RC4 contains only documentation fixes reported on RC3 (thanks to Michael Heuer). There is one minor formatting issue that causes extra spaces after some anchors, that appears to be a maven formatting issue. Again, not sure if another vote is necessary, since plenty of +1s have come in for the previous RCs, but I don't want to presume anything: [ ] +1 [ ] -1 -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] (RE)VOTE 2.1 Release
I have fixed all the items noted below with the exception of the extra space behind the links. This is some sort of maven issue that I haven't figured out yet. I propose we go ahead and release since there is no material problem, just a minor formatting issue. I will call a vot in a separate thread. On 4/26/05, Michael Heuer [EMAIL PROTECTED] wrote: A few minor nits with the web site: Links before commas and periods have an extra space, e.g. lang status document . and Maven , JDiff , PMD , FindBugs on index.html. I had thought that this issue was resolved in an upgrade to maven and/or the maven xdoc plugin? Update tasks.html, user guide has been written. (it is quite nice, by the way) Give userguide.html a header similar to that of developerguide.html. userguide.html abbout -- about userguide.html use codeCharSetUtils.delete(testtest, tr)/code instead of 'CharSetUtils.delete(testtest, tr)' ? What about the other methods used in the text, should they be put in code tags as well? developerguide.html nessesary -- necessary A non-binding +1 from me. michael On Tue, 26 Apr 2005, Steven Caswell wrote: Release candidate 3 (and hopefully final :) is in http://www.apache.org/~stevencaswell/commons-lang-2.1/ The only changes between RC2 and RC3 are documentation clean-up (thanks to Gary for finding some inconsistencies). It would be good if someone could check the compatibility of the distribution with JDK 1.2. I know Stephen asked for a clirr, and I haven't had time to work on that, but I should be able to get it by tomorrow evening (ET). Not sure if another vote is necessary since I don't recall any -1s, but I'll go ahead and propose it and see what shakes out: [ ] +1 [ ] -1 -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
[lang] New VOTE on lang release
Release candidate 4 is in http://www.apache.org/~stevencaswell/commons-lang-2.1/http://www.apache.org/%7Estevencaswell/commons-lang-2.1/ RC4 contains only documentation fixes reported on RC3 (thanks to Michael Heuer). There is one minor formatting issue that causes extra spaces after some anchors, that appears to be a maven formatting issue. Again, not sure if another vote is necessary, since plenty of +1s have come in for the previous RCs, but I don't want to presume anything: [ ] +1 [ ] -1 -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] (RE)VOTE 2.1 Release
No problem. I can just about do it in my sleep now :) On 4/26/05, Gary Gregory [EMAIL PROTECTED] wrote: If the changes below are committed, we'll need an RC4... sorry for the extra work Steven, by now you must have it turn-key ;-) Gary -Original Message- From: Michael Heuer [mailto:[EMAIL PROTECTED] On Behalf Of Michael Heuer Sent: Tuesday, April 26, 2005 9:22 AM To: Jakarta Commons Developers List; Steven Caswell Subject: Re: [lang] (RE)VOTE 2.1 Release A few minor nits with the web site: Links before commas and periods have an extra space, e.g. lang status document . and Maven , JDiff , PMD , FindBugs on index.html. I had thought that this issue was resolved in an upgrade to maven and/or the maven xdoc plugin? Update tasks.html, user guide has been written. (it is quite nice, by the way) Give userguide.html a header similar to that of developerguide.html. userguide.html abbout -- about userguide.html use codeCharSetUtils.delete(testtest, tr)/code instead of 'CharSetUtils.delete(testtest, tr)' ? What about the other methods used in the text, should they be put in code tags as well? developerguide.html nessesary -- necessary A non-binding +1 from me. michael On Tue, 26 Apr 2005, Steven Caswell wrote: Release candidate 3 (and hopefully final :) is in http://www.apache.org/~stevencaswell/commons-lang-2.1/ The only changes between RC2 and RC3 are documentation clean-up (thanks to Gary for finding some inconsistencies). It would be good if someone could check the compatibility of the distribution with JDK 1.2. I know Stephen asked for a clirr, and I haven't had time to work on that, but I should be able to get it by tomorrow evening (ET). Not sure if another vote is necessary since I don't recall any -1s, but I'll go ahead and propose it and see what shakes out: [ ] +1 [ ] -1 -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
[lang] (RE)VOTE 2.1 Release
I have posted the clirr report for review: http://www.apache.org/~stevencaswell/commons-lang-2.1/clirr-2.0-to-2.1.txt -- Forwarded message -- From: Steven Caswell [EMAIL PROTECTED] Date: Apr 26, 2005 7:31 AM Subject: [lang] (RE)VOTE 2.1 Release To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Release candidate 3 (and hopefully final :) is in http://www.apache.org/~stevencaswell/commons-lang-2.1/http://www.apache.org/%7Estevencaswell/commons-lang-2.1/ The only changes between RC2 and RC3 are documentation clean-up (thanks to Gary for finding some inconsistencies). It would be good if someone could check the compatibility of the distribution with JDK 1.2. I know Stephen asked for a clirr, and I haven't had time to work on that, but I should be able to get it by tomorrow evening (ET). Not sure if another vote is necessary since I don't recall any -1s, but I'll go ahead and propose it and see what shakes out: [ ] +1 [ ] -1 -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
[lang] (RE)VOTE 2.1 Release
Release candidate 3 (and hopefully final :) is in http://www.apache.org/~stevencaswell/commons-lang-2.1/ The only changes between RC2 and RC3 are documentation clean-up (thanks to Gary for finding some inconsistencies). It would be good if someone could check the compatibility of the distribution with JDK 1.2. I know Stephen asked for a clirr, and I haven't had time to work on that, but I should be able to get it by tomorrow evening (ET). Not sure if another vote is necessary since I don't recall any -1s, but I'll go ahead and propose it and see what shakes out: [ ] +1 [ ] -1 -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] VOTE 2.1 release
Good catch. Will fix. On 4/19/05, Gary Gregory [EMAIL PROTECTED] wrote: On the Maven site, there still are references to CVS : The Repository section says CVS Repositoryhttp://cvs.apache.org/viewcvs/jakarta-commons/lang/ and points to the CVS repos. The menu area lists CVS and Javadoc (CVS latest)http://people.apache.org/%7Estevencaswell/commons-lang-2.1/docs/apidocs/index.html Gary -- *From:* Steven Caswell [mailto:[EMAIL PROTECTED] *Sent:* Tuesday, April 19, 2005 1:41 PM *To:* Henri Yandell *Cc:* Gary Gregory; Jakarta Commons Developers List *Subject:* Re: [lang] VOTE 2.1 release RC2 is now available at http://www.apache.org/~stevencaswell/commons-lang-2.1http://www.apache.org/%7Estevencaswell/commons-lang-2.1 As per discussions, site stuff was built with maven while the distributions were build using Ant against JDK 1.2.2. A couple of other minor things to note: - I added a bit of verbiage to the user's guide about the new 2.1 stuff. It is pretty sparse, so if someone wants to beef it up a little... - I updated the overview to reflect 2.1 - I updated the repository url in project.xml to point to the viewcvs version of the repository to get the more robust view of svn. It looks like maven generates the url differently now based on the RC1 docs. Do we want to call a new vote? On 4/17/05, *Henri Yandell* [EMAIL PROTECTED] wrote: Unsure. I thought I was committed, so things like the overview were probably missed. I need to take the car in on Monday, so am spending a lot of the weekend getting next weeks work done in advance :) Maybe Steve would like to knock out an RC2? The only thing that's peculiar to my setup is that I have the JDiff stuff setup with scripts instead of trying to do it through Maven. Legacy mainly. Important to get the JDK 1.2 vs 1.4 stuff right. Namely run Maven under 1.4 and Ant under 1.2. Use the binaries from Ant and get the rest (src, site) from Maven. Hen On 4/17/05, Gary Gregory [EMAIL PROTECTED] wrote: Hello Hen: Do you have 2.0 changed to 2.1 as local changes not in CVS? For example in /lang/src/java/org/apache/commons/lang/overview.html Also, how about an RC-2 to cover the last batch of commits? Thanks, Gary -Original Message- From: Steven Caswell [mailto: [EMAIL PROTECTED] Sent: Thursday, April 14, 2005 2:44 PM To: Jakarta Commons Developers List; Henri Yandell Subject: Re: [lang] VOTE 2.1 release Looks good. +1 I'd be glad to do the release if someone wouldn't mind walking me through it since I've never done one. On 4/10/05, Henri Yandell [EMAIL PROTECTED] wrote: Proposing a vote to go ahead and release Commons Lang 2.1. The release will pretty much match the release-candidate that is in: http://www.apache.org/~bayard/commons-lang-2.1/http://www.apache.org/%7Ebayard/commons-lang-2.1/ Stephen's recent defaultIfEmpty method will be included in the release. If the vote is successful, I'll target spending next weekend performing the release (unless anyone wants to volunteer). [ ] +1 [ ] -1 Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] VOTE 2.1 release
Gee, I just read my response about looking at things a dozen times, and if I didn't know better I'd say it might have come across the wrong way. Just so I didn't cause any confusion, my You was meant as a collective you, not a You aimed at anyone (like Gary). Please do keep looking. On 4/19/05, Gary Gregory [EMAIL PROTECTED] wrote: J I'll keep on looking. Gary -- *From:* Steven Caswell [mailto:[EMAIL PROTECTED] *Sent:* Tuesday, April 19, 2005 6:03 PM *To:* Gary Gregory *Cc:* Henri Yandell; Jakarta Commons Developers List *Subject:* Re: [lang] VOTE 2.1 release You can look at these things a dozen times and still miss the obvious. I'll put this on the list to fix before it goes out. On 4/19/05, *Gary Gregory* [EMAIL PROTECTED] wrote: Hello: The file docs/api/index.html in http://people.apache.org/~stevencaswell/commons-lang-2.1/distributions/commons-lang-2.1-RC2.ziphttp://people.apache.org/%7Estevencaswell/commons-lang-2.1/distributions/commons-lang-2.1-RC2.zip still says 2.0. Gary -- *From:* Steven Caswell [mailto: [EMAIL PROTECTED] *Sent:* Tuesday, April 19, 2005 1:41 PM *To:* Henri Yandell *Cc:* Gary Gregory; Jakarta Commons Developers List *Subject:* Re: [lang] VOTE 2.1 release RC2 is now available at http://www.apache.org/~stevencaswell/commons-lang-2.1http://www.apache.org/%7Estevencaswell/commons-lang-2.1 As per discussions, site stuff was built with maven while the distributions were build using Ant against JDK 1.2.2. A couple of other minor things to note: - I added a bit of verbiage to the user's guide about the new 2.1 stuff. It is pretty sparse, so if someone wants to beef it up a little... - I updated the overview to reflect 2.1 - I updated the repository url in project.xml to point to the viewcvs version of the repository to get the more robust view of svn. It looks like maven generates the url differently now based on the RC1 docs. Do we want to call a new vote? On 4/17/05, *Henri Yandell* [EMAIL PROTECTED] wrote: Unsure. I thought I was committed, so things like the overview were probably missed. I need to take the car in on Monday, so am spending a lot of the weekend getting next weeks work done in advance :) Maybe Steve would like to knock out an RC2? The only thing that's peculiar to my setup is that I have the JDiff stuff setup with scripts instead of trying to do it through Maven. Legacy mainly. Important to get the JDK 1.2 vs 1.4 stuff right. Namely run Maven under 1.4 and Ant under 1.2. Use the binaries from Ant and get the rest (src, site) from Maven. Hen On 4/17/05, Gary Gregory [EMAIL PROTECTED] wrote: Hello Hen: Do you have 2.0 changed to 2.1 as local changes not in CVS? For example in /lang/src/java/org/apache/commons/lang/overview.html Also, how about an RC-2 to cover the last batch of commits? Thanks, Gary -Original Message- From: Steven Caswell [mailto: [EMAIL PROTECTED] Sent: Thursday, April 14, 2005 2:44 PM To: Jakarta Commons Developers List; Henri Yandell Subject: Re: [lang] VOTE 2.1 release Looks good. +1 I'd be glad to do the release if someone wouldn't mind walking me through it since I've never done one. On 4/10/05, Henri Yandell [EMAIL PROTECTED] wrote: Proposing a vote to go ahead and release Commons Lang 2.1. The release will pretty much match the release-candidate that is in: http://www.apache.org/~bayard/commons-lang-2.1/http://www.apache.org/%7Ebayard/commons-lang-2.1/ Stephen's recent defaultIfEmpty method will be included in the release. If the vote is successful, I'll target spending next weekend performing the release (unless anyone wants to volunteer). [ ] +1 [ ] -1 Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] VOTE 2.1 release
RC2 is now available at http://www.apache.org/~stevencaswell/commons-lang-2.1 As per discussions, site stuff was built with maven while the distributions were build using Ant against JDK 1.2.2. A couple of other minor things to note: - I added a bit of verbiage to the user's guide about the new 2.1 stuff. It is pretty sparse, so if someone wants to beef it up a little... - I updated the overview to reflect 2.1 - I updated the repository url in project.xml to point to the viewcvs version of the repository to get the more robust view of svn. It looks like maven generates the url differently now based on the RC1 docs. Do we want to call a new vote? On 4/17/05, Henri Yandell [EMAIL PROTECTED] wrote: Unsure. I thought I was committed, so things like the overview were probably missed. I need to take the car in on Monday, so am spending a lot of the weekend getting next weeks work done in advance :) Maybe Steve would like to knock out an RC2? The only thing that's peculiar to my setup is that I have the JDiff stuff setup with scripts instead of trying to do it through Maven. Legacy mainly. Important to get the JDK 1.2 vs 1.4 stuff right. Namely run Maven under 1.4 and Ant under 1.2. Use the binaries from Ant and get the rest (src, site) from Maven. Hen On 4/17/05, Gary Gregory [EMAIL PROTECTED] wrote: Hello Hen: Do you have 2.0 changed to 2.1 as local changes not in CVS? For example in /lang/src/java/org/apache/commons/lang/overview.html Also, how about an RC-2 to cover the last batch of commits? Thanks, Gary -Original Message- From: Steven Caswell [mailto:[EMAIL PROTECTED] Sent: Thursday, April 14, 2005 2:44 PM To: Jakarta Commons Developers List; Henri Yandell Subject: Re: [lang] VOTE 2.1 release Looks good. +1 I'd be glad to do the release if someone wouldn't mind walking me through it since I've never done one. On 4/10/05, Henri Yandell [EMAIL PROTECTED] wrote: Proposing a vote to go ahead and release Commons Lang 2.1. The release will pretty much match the release-candidate that is in: http://www.apache.org/~bayard/commons-lang-2.1/ Stephen's recent defaultIfEmpty method will be included in the release. If the vote is successful, I'll target spending next weekend performing the release (unless anyone wants to volunteer). [ ] +1 [ ] -1 Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] VOTE 2.1 release
You can look at these things a dozen times and still miss the obvious. I'll put this on the list to fix before it goes out. On 4/19/05, Gary Gregory [EMAIL PROTECTED] wrote: Hello: The file docs/api/index.html in http://people.apache.org/~stevencaswell/commons-lang-2.1/distributions/commons-lang-2.1-RC2.ziphttp://people.apache.org/%7Estevencaswell/commons-lang-2.1/distributions/commons-lang-2.1-RC2.zip still says 2.0. Gary -- *From:* Steven Caswell [mailto:[EMAIL PROTECTED] *Sent:* Tuesday, April 19, 2005 1:41 PM *To:* Henri Yandell *Cc:* Gary Gregory; Jakarta Commons Developers List *Subject:* Re: [lang] VOTE 2.1 release RC2 is now available at http://www.apache.org/~stevencaswell/commons-lang-2.1http://www.apache.org/%7Estevencaswell/commons-lang-2.1 As per discussions, site stuff was built with maven while the distributions were build using Ant against JDK 1.2.2. A couple of other minor things to note: - I added a bit of verbiage to the user's guide about the new 2.1 stuff. It is pretty sparse, so if someone wants to beef it up a little... - I updated the overview to reflect 2.1 - I updated the repository url in project.xml to point to the viewcvs version of the repository to get the more robust view of svn. It looks like maven generates the url differently now based on the RC1 docs. Do we want to call a new vote? On 4/17/05, *Henri Yandell* [EMAIL PROTECTED] wrote: Unsure. I thought I was committed, so things like the overview were probably missed. I need to take the car in on Monday, so am spending a lot of the weekend getting next weeks work done in advance :) Maybe Steve would like to knock out an RC2? The only thing that's peculiar to my setup is that I have the JDiff stuff setup with scripts instead of trying to do it through Maven. Legacy mainly. Important to get the JDK 1.2 vs 1.4 stuff right. Namely run Maven under 1.4 and Ant under 1.2. Use the binaries from Ant and get the rest (src, site) from Maven. Hen On 4/17/05, Gary Gregory [EMAIL PROTECTED] wrote: Hello Hen: Do you have 2.0 changed to 2.1 as local changes not in CVS? For example in /lang/src/java/org/apache/commons/lang/overview.html Also, how about an RC-2 to cover the last batch of commits? Thanks, Gary -Original Message- From: Steven Caswell [mailto: [EMAIL PROTECTED] Sent: Thursday, April 14, 2005 2:44 PM To: Jakarta Commons Developers List; Henri Yandell Subject: Re: [lang] VOTE 2.1 release Looks good. +1 I'd be glad to do the release if someone wouldn't mind walking me through it since I've never done one. On 4/10/05, Henri Yandell [EMAIL PROTECTED] wrote: Proposing a vote to go ahead and release Commons Lang 2.1. The release will pretty much match the release-candidate that is in: http://www.apache.org/~bayard/commons-lang-2.1/http://www.apache.org/%7Ebayard/commons-lang-2.1/ Stephen's recent defaultIfEmpty method will be included in the release. If the vote is successful, I'll target spending next weekend performing the release (unless anyone wants to volunteer). [ ] +1 [ ] -1 Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] VOTE 2.1 release
Can someone remind me how to handle the clover license? It's been a while since I tried a site build with lang, and I get the message This license has `expired, which looks like it is coming from clover. TIA On 4/17/05, Henri Yandell [EMAIL PROTECTED] wrote: Unsure. I thought I was committed, so things like the overview were probably missed. I need to take the car in on Monday, so am spending a lot of the weekend getting next weeks work done in advance :) Maybe Steve would like to knock out an RC2? The only thing that's peculiar to my setup is that I have the JDiff stuff setup with scripts instead of trying to do it through Maven. Legacy mainly. Important to get the JDK 1.2 vs 1.4 stuff right. Namely run Maven under 1.4 and Ant under 1.2. Use the binaries from Ant and get the rest (src, site) from Maven. Hen On 4/17/05, Gary Gregory [EMAIL PROTECTED] wrote: Hello Hen: Do you have 2.0 changed to 2.1 as local changes not in CVS? For example in /lang/src/java/org/apache/commons/lang/overview.html Also, how about an RC-2 to cover the last batch of commits? Thanks, Gary -Original Message- From: Steven Caswell [mailto:[EMAIL PROTECTED] Sent: Thursday, April 14, 2005 2:44 PM To: Jakarta Commons Developers List; Henri Yandell Subject: Re: [lang] VOTE 2.1 release Looks good. +1 I'd be glad to do the release if someone wouldn't mind walking me through it since I've never done one. On 4/10/05, Henri Yandell [EMAIL PROTECTED] wrote: Proposing a vote to go ahead and release Commons Lang 2.1. The release will pretty much match the release-candidate that is in: http://www.apache.org/~bayard/commons-lang-2.1/ Stephen's recent defaultIfEmpty method will be included in the release. If the vote is successful, I'll target spending next weekend performing the release (unless anyone wants to volunteer). [ ] +1 [ ] -1 Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] VOTE 2.1 release
I think I figured out how to get clover to work by making the following adjustments: In project.xml, make sure the following properties are set: maven.jar.override=on maven.jar.clover=1.3.2 maven.clover.license=clover.license Copy the clover.license file from the committers svn repository to the base directory. Also copy the clover.license file from the commiters svn repository to .maven/repository/clover/licenses/clover-1.3.2.license (apparently the 1.3.2comes from the maven.jar.clover setting) I'm not sure I understand why I don't need to copy over clover.jar from committers svn, but I apparently don't need it. On 4/17/05, Henri Yandell [EMAIL PROTECTED] wrote: Ack, I forgot about that. The standard Maven licence expired. I'm using the apache Clover licence, (available in the committers svn repository), but it needs a later Clover jar and I've noticed that the way I was making Maven use this later jar no longer works in the latest Maven. So I was using an older Maven version. Hen On 4/17/05, Steven Caswell [EMAIL PROTECTED] wrote: Can someone remind me how to handle the clover license? It's been a while since I tried a site build with lang, and I get the message This license has `expired, which looks like it is coming from clover. TIA On 4/17/05, Henri Yandell [EMAIL PROTECTED] wrote: Unsure. I thought I was committed, so things like the overview were probably missed. I need to take the car in on Monday, so am spending a lot of the weekend getting next weeks work done in advance :) Maybe Steve would like to knock out an RC2? The only thing that's peculiar to my setup is that I have the JDiff stuff setup with scripts instead of trying to do it through Maven. Legacy mainly. Important to get the JDK 1.2 vs 1.4 stuff right. Namely run Maven under 1.4 and Ant under 1.2. Use the binaries from Ant and get the rest (src, site) from Maven. Hen On 4/17/05, Gary Gregory [EMAIL PROTECTED] wrote: Hello Hen: Do you have 2.0 changed to 2.1 as local changes not in CVS? For example in /lang/src/java/org/apache/commons/lang/overview.html Also, how about an RC-2 to cover the last batch of commits? Thanks, Gary -Original Message- From: Steven Caswell [mailto: [EMAIL PROTECTED] Sent: Thursday, April 14, 2005 2:44 PM To: Jakarta Commons Developers List; Henri Yandell Subject: Re: [lang] VOTE 2.1 release Looks good. +1 I'd be glad to do the release if someone wouldn't mind walking me through it since I've never done one. On 4/10/05, Henri Yandell [EMAIL PROTECTED] wrote: Proposing a vote to go ahead and release Commons Lang 2.1. The release will pretty much match the release-candidate that is in: http://www.apache.org/~bayard/commons-lang-2.1/ Stephen's recent defaultIfEmpty method will be included in the release. If the vote is successful, I'll target spending next weekend performing the release (unless anyone wants to volunteer). [ ] +1 [ ] -1 Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] VOTE 2.1 release
Is there a convenient way to install both JDK 1.4 and 1.2 on a Windows system and switch between the two for building the 1.4 maven site and the 1.2 ant binaries? Or do I need to different systems with one of that installed on each? TIA. On 4/17/05, Phil Steitz [EMAIL PROTECTED] wrote: On 4/17/05, Henri Yandell [EMAIL PROTECTED] wrote: Unsure. I thought I was committed, so things like the overview were probably missed. I need to take the car in on Monday, so am spending a lot of the weekend getting next weeks work done in advance :) Maybe Steve would like to knock out an RC2? The only thing that's peculiar to my setup is that I have the JDiff stuff setup with scripts instead of trying to do it through Maven. Legacy mainly. Important to get the JDK 1.2 vs 1.4 stuff right. Namely run Maven under 1.4 and Ant under 1.2. Use the binaries from Ant and get the rest (src, site) from Maven. Can someone (gently) enlighten me as to why it is better to build the release binaries using 1.2? IIRC, for 2.0 we tested builds with 1.2, but make the release binaries using 1.4. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] VOTE 2.1 release
I think the problem is that there is more than just the JAVA_HOME and PATH to worry about. There are some registry setting that get changed, specifically a setting that indicates the installed version. I'll just wait until tomorrow and do the RC2 build at work on a Unix box. I've gotten everything else done on my local Windows (site build, jdiff, etc.) so installing 1.2 and doing the binary build on Unix shouldn't be too much trouble. On 4/17/05, Henri Yandell [EMAIL PROTECTED] wrote: Write yourself tiny .bat scripts which adjust PATH and JAVA_HOME? Should be as applicable on Windows as Linux. Different users is another possiiblity. As long as you add the new PATH entry at the front each time, it should find that one first. Hope that helps, Hen On 4/17/05, Steven Caswell [EMAIL PROTECTED] wrote: Is there a convenient way to install both JDK 1.4 and 1.2 on a Windows system and switch between the two for building the 1.4 maven site and the 1.2 ant binaries? Or do I need to different systems with one of that installed on each? TIA. On 4/17/05, Phil Steitz [EMAIL PROTECTED] wrote: On 4/17/05, Henri Yandell [EMAIL PROTECTED] wrote: Unsure. I thought I was committed, so things like the overview were probably missed. I need to take the car in on Monday, so am spending a lot of the weekend getting next weeks work done in advance :) Maybe Steve would like to knock out an RC2? The only thing that's peculiar to my setup is that I have the JDiff stuff setup with scripts instead of trying to do it through Maven. Legacy mainly. Important to get the JDK 1.2 vs 1.4 stuff right. Namely run Maven under 1.4 and Ant under 1.2. Use the binaries from Ant and get the rest (src, site) from Maven. Can someone (gently) enlighten me as to why it is better to build the release binaries using 1.2? IIRC, for 2.0 we tested builds with 1.2, but make the release binaries using 1.4. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] VOTE 2.1 release
On 4/17/05, Henri Yandell [EMAIL PROTECTED] wrote: On 4/17/05, Steven Caswell [EMAIL PROTECTED] wrote: I think I figured out how to get clover to work by making the following adjustments: In project.xml, make sure the following properties are set: maven.jar.override=on maven.jar.clover=1.3.2 maven.clover.license=clover.license Yep. I think the 1.3.2 bit broke in the latest Maven, but maybe not. Copy the clover.license file from the committers svn repository to the base directory. Unsure if this is necessary. Also copy the clover.license file from the commiters svn repository to .maven/repository/clover/licenses/clover-1.3.2.license (apparently the 1.3.2 comes from the maven.jar.clover setting) Ah. I'd historically just put it in without the 1.3.2; maybe that's the change that broke things for me. I put it in next to the jar file in the repository. I'm not sure I understand why I don't need to copy over clover.jar from committers svn, but I apparently don't need it. It's the same as the clover-1.3.2.jar that is uploaded to ibiblio.orghttp://ibiblio.org and being downloaded by the override. Thanks for doing this, Hen I haven't gone through the plugin script, but there is something in the script that looks for the maven.clover.license.path property, and it gave me an exception when this property wasn't set. I had to set the property to point to the clover.license, and I had to copy it to the licenses directory. There may be some simpler combination, but I didn't take the time to try to figure it out. This combination worked and I was just happy for that :) My pleasure to work on this. I haven't been very active lately and this is something simple enough that I can contribute. -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] VOTE 2.1 release
Looks good. +1 I'd be glad to do the release if someone wouldn't mind walking me through it since I've never done one. On 4/10/05, Henri Yandell [EMAIL PROTECTED] wrote: Proposing a vote to go ahead and release Commons Lang 2.1. The release will pretty much match the release-candidate that is in: http://www.apache.org/~bayard/commons-lang-2.1/ Stephen's recent defaultIfEmpty method will be included in the release. If the vote is successful, I'll target spending next weekend performing the release (unless anyone wants to volunteer). [ ] +1 [ ] -1 Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: [lang] return statements [was VOTE 2.1 release]
For me this is not too terribly religious, as opposed to say, oh, something like bracket placement ;) Either way is fine with me. On Apr 12, 2005 3:13 AM, Stephen Colebourne [EMAIL PROTECTED] wrote: Personally I think its a lot more readable with the brackets (unless its a simple return). Thus I tend to code as: return value; return method(); return (expression); But if others dislike this, I'll try to remembre not to do it on lang. Better put it in the lang guidelines though. Stephe Henri Yandell wrote: -1 to return (foo) :) You get my vote to commit. I'm pretty sure the general agreement is to not have brackets on return statements, but I'm unsure if it's some contributors or some committers who like the brackets. Hen On Apr 11, 2005 6:56 PM, Gary Gregory [EMAIL PROTECTED] wrote: Hello: I've committed some small clean ups in the text package which will not be shipped in 2.1. What I found while doing this is a code style inconsistency that I've fixed locally but not committed yet. Since this involves style (religion ;-) I did not want to commit without posting here first: Throughout [lang], some return statements are coded as the standard: return expression; While others are coded as with extra C-style ( and ): return (expression); I did not find any pattern to either style. I removed extra ( and ) in return expressions on my local store. Is this a religious issue for some [lang]'ers out there or should I just commit? Thanks, Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Sunday, April 10, 2005 5:54 PM To: Jakarta Commons Developers List Subject: [lang] VOTE 2.1 release Proposing a vote to go ahead and release Commons Lang 2.1. The release will pretty much match the release-candidate that is in: http://www.apache.org/~bayard/commons-lang-2.1/ Stephen's recent defaultIfEmpty method will be included in the release. If the vote is successful, I'll target spending next weekend performing the release (unless anyone wants to volunteer). [ ] +1 [ ] -1 Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org
Re: Distributions to include dependencies?
I'm +1 to Henri's idea for this reason: When I'm using a package that requires other jars, I typically install the package on my development platform way ahead of the time when I'll be running maven. On some projects I never even run maven on the development box. Having the dependent jars as part of the distro is very convenient for setting up the development environment. I'd otherwise have to go manually find each one. Steven Caswell [EMAIL PROTECTED] -- Original Message -- From: Phil Steitz [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Date: Mon, 27 Dec 2004 16:09:01 -0500 Henri Yandell wrote: On Mon, 27 Dec 2004 15:14:36 -0500, Phil Steitz [EMAIL PROTECTED] wrote: Henri Yandell wrote: Not a huge issue for things like Lang which have no dependencies, but for other things like Digester I think it would be a lot better if the binary tar.gz contained the jars it depends on? Just my HO, but to me that defeats the purpose of ibiblio/java-repository. It also bloats distros and adds to the effective contract of the distro and responsibility of the RM needlessly (Would doing this effectively require us to store whatever jars were grabbed at release time in cvs/svn?) Nope. The jars come from the ibiblio/java-repo at dist-time. That's what I mean. The release would depend on jars grabbed from external sources at dist-time. Some would argue that everything necessary to generate the release distribution should be under revision control, so the exact contents of the release could be reproduced (or verified) at a later time by checking out the tagged sources and rebuilding. A maven user would still use it in the same way, but maven users do not use the tar.gz distributions, they use the jars in the repos. I may be in the minority here, but I have never liked the bundle all dependencies for convenience approach -- either as a user or as a developer. As a user, I am never sure exactly what I am getting in the bundled version cut dependencies/commons-logging-1.0.3.jar dependencies/commons-beanutils-1.7.jar cut I understand that for complex products like struts or tomcat, it may be impractical *not* to bundle dependencies; but I do not see it as necessary for commons components. If I download the digester.tar.gz, I then need to download the logging.tar.gz and the beanutils.tar.gz. Personally, I do not see this as a big deal. Our mirrors are fast :-) Maven handles it all seamlessly and for ant builds or web app deployments, you generally want to place the jars manually anyway. Phil Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] bug#30929 - use isAssignableFrom
The bug author makes a good point. I'm +1 to making the change. Steven Caswell Sun Certified Java Programmer [EMAIL PROTECTED] War is an ugly thing, but not the ugliest of things. The decayed and degraded state of moral and patriotic feeling that thinks that nothing is worth war is much worse. The person who has nothing for which he is willing to fight, nothing which is more important than his own personal safety, is a miserable creature and has no chance of being free unless made and kept so by the exertions of better men than himself. John Stuart Mill. -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Thursday, September 30, 2004 2:06 AM To: Jakarta Commons Developers List Subject: [lang] bug#30929 - use isAssignableFrom I think this bug makes sense: http://issues.apache.org/bugzilla/show_bug.cgi?id=30929 Assuming no one disagrees, do we want to make the change in indexOfThrowable or create a new method? The javadoc for indexOfThrowable says 'type', which to me would imply inheritence is adhered to. I ask as the unit tests fail if the change is made and before I'd rather not waste the time on them if people are against the change. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] find API Was: [IO] DOSFileFilter
WildcardUtils look general enough that it could go into commons-lang, but then of course you introduce a dependency, which seems to give some people a lot more heartburn than it gives me. I hate to see classes put into the wrong library just to avoid even dependencies that make sense. -- Original Message -- From: Henri Yandell [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] Date: Thu, 9 Sep 2004 02:20:18 -0400 (EDT) Not time to commit tonight, but it's at: http://www.osjava.org/genjava/multiproject/gj-find/xref/index.html WildcardUtils. It's tempting to commit most of gj-find to IO. A Java API with similarity to the unix find command, though ignore ZipFinder as that's dead. Any views? Hen On Wed, 8 Sep 2004, Henri Yandell wrote: It'll appear in commons-io/src/java somewhere. My main server just blew up, so I might not get around to it tonight, but I should be able to. Hen On Wed, 8 Sep 2004 [EMAIL PROTECTED] wrote: Thanks, where will you upload to? Jason -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 08, 2004 5:13 PM To: Jakarta Commons Developers List Subject: RE: [IO] DOSFileFilter No worries, I've already got a Wildcard parser that I'll upload :) Hen On Wed, 8 Sep 2004 [EMAIL PROTECTED] wrote: Fair enough, i'm sure there must be some people using 1.2 (although i dont know any) and the baseline should be consistent across the commons libraries. Will have to rewrite without regexp! Jason -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 08, 2004 2:59 PM To: Jakarta Commons Developers List Subject: RE: [IO] DOSFileFilter (now my email is fixed, I can reply). We're targetting JDK 1.2, though I'm always completely happy to depend on 1.4 if the community wants to. Can't remember when I last used 1.3 or earlier. Hen IMPORTANT NOTICE Email from OOCL is confidential and may be legally privileged. If it is not intended for you, please delete it immediately unread. The internet cannot guarantee that this communication is free of viruses, interception or interference and anyone who communicates with us by email is taken to accept the risks in so doing. Without limitation, OOCL and its affiliates accept no liability whatsoever and howsoever arising in connection with the use of this email. Under no circumstances shall this email constitute a binding agreement to carry or for provision of carriage services by OOCL, which is subject to the availability of carrier's equipment and vessels and the terms and conditions of OOCL's standard bill of lading which is also available at http://www.oocl.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] IMPORTANT NOTICE Email from OOCL is confidential and may be legally privileged. If it is not intended for you, please delete it immediately unread. The internet cannot guarantee that this communication is free of viruses, interception or interference and anyone who communicates with us by email is taken to accept the risks in so doing. Without limitation, OOCL and its affiliates accept no liability whatsoever and howsoever arising in connection with the use of this email. Under no circumstances shall this email constitute a binding agreement to carry or for provision of carriage services by OOCL, which is subject to the availability of carrier's equipment and vessels and the terms and conditions of OOCL's standard bill of lading which is also available at http://www.oocl.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] NestableException subclass NestableIOException?
Sorry it took so long to respond. I have to agree with the others that it is too specific. Steven Caswell Sun Certified Java Programmer [EMAIL PROTECTED] War is an ugly thing, but not the ugliest of things. The decayed and degraded state of moral and patriotic feeling that thinks that nothing is worth war is much worse. The person who has nothing for which he is willing to fight, nothing which is more important than his own personal safety, is a miserable creature and has no chance of being free unless made and kept so by the exertions of better men than himself. John Stuart Mill. -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 04, 2004 1:50 PM To: Jakarta Commons Developers List Subject: Re: [lang] NestableException subclass NestableIOException? Too specific I think. Hen On Tue, 3 Aug 2004, Gary Gregory wrote: Hello, I need a subclass of IOException that is really a NestableException so I am wondering if a NestableIOException (extends IOException) would be a good addition to lang.e or if it is too specific. If not, that's fine, I'll create it for our app's internal use only. Thanks. Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [io] Deprecate CopyUtils
I'm not an io committer, so this is just my $.02. I usually agree that significant API changes aren't the best approach, but in this case I think it is better to get it right now. I've used CopyUtils in a couple of places, and I would not get heartburn having to change my code knowing the API was changing for the better. Granted I have only a few changes to make, and I might feel differently if I had bunches. But again, making the API better seems to be the right approach in this case. Steven Caswell Sun Certified Java Programmer [EMAIL PROTECTED] War is an ugly thing, but not the ugliest of things. The decayed and degraded state of moral and patriotic feeling that thinks that nothing is worth war is much worse. The person who has nothing for which he is willing to fight, nothing which is more important than his own personal safety, is a miserable creature and has no chance of being free unless made and kept so by the exertions of better men than himself. John Stuart Mill. -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Saturday, July 31, 2004 6:57 AM To: Jakarta Commons Developers List Subject: [io] Deprecate CopyUtils I have been looking at adding methods to IOUtils/CopyUtils, to handle additional types and to fix some holes. The net result is a realisation that the CopyUtils class was a poor creation (and it may even have been my idea!). - CopyUtils implements various methods that write byte[] and String to stream/writer but to this inefficiently via other writers/streams. - null handling is unclear. - the toXxx methods on IOUtils are strongly related to CopyUtils yet they are on a different class (they are the read() operations) - it is not logical to look on a 'copy' class to find a method when I just want to 'write' data (write a string/byte[] to file is not a copy operation in most peoples minds.) So, I propose the following: CopyUtils deprecated, methods moved to IOUtils. Write methods (string/byte[] to stream) are renamed to write(...) Copy methods (stream to stream) stay named as copy(...) The write methods will also change implementation to handle null string/byte[] and to be more efficient. The main downside is that it annoys users who are using CopyUtils. However, it does seem to be better to fix the issue and get the right API. Alternatives would include ReaderUtils, WriterUtils, InputStreamUtils, OutputStreamUtils, but then where do the actual copy methods go. Plus too much breaking up can be troublesome for users too. This strategy of IOUtils for low level streams/readers/writers and FileUtils for higher level files and FilenameUtils for even higher level seems to work well in my mind. If there are no objections I will commit these changes Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] Stopwatch improvements
I think it makes sense to be able to stop from suspend. That would give the caller the most options. Otherwise, if the stopwatch were suspended, you'd have to restart it before stopping, which would change the time of the stopwatch. Being able to stop while suspended means you can stop from suspend without the time changing, but a caller could still resume and then stop if they wanted that functionality. For reset when state is running or split, I think that should not be allowed. I think the stopwatch can only be reset if the stopwatch is stopped. That keeps the methods cleaner while still providing the necessary functionality. Steven Caswell Sun Certified Java Programmer [EMAIL PROTECTED] War is an ugly thing, but not the ugliest of things. The decayed and degraded state of moral and patriotic feeling that thinks that nothing is worth war is much worse. The person who has nothing for which he is willing to fight, nothing which is more important than his own personal safety, is a miserable creature and has no chance of being free unless made and kept so by the exertions of better men than himself. John Stuart Mill. -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Sunday, July 18, 2004 6:43 PM To: 'Jakarta Commons Developers List' Subject: [lang] Stopwatch improvements I've put in the suggested state for the Stopwatch class into the Bugzilla issue: http://issues.apache.org/bugzilla/show_bug.cgi?id=29163 One major issue is that it changes the functionality of Stopwatch quite a lot, so I suspect that it should be held back for 3.0. Opinions very welcome, on both the state suggestion and whether it should be held for 3.0. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] StringUtils.split ignores empty items (Bugzilla bug# 22692)
I went ahead and named it splitPreserveAllTokens, since that seemed to be the closest concensus. It would be good if someone could review. Steven Caswell Sun Certified Java Programmer [EMAIL PROTECTED] War is an ugly thing, but not the ugliest of things. The decayed and degraded state of moral and patriotic feeling that thinks that nothing is worth war is much worse. The person who has nothing for which he is willing to fight, nothing which is more important than his own personal safety, is a miserable creature and has no chance of being free unless made and kept so by the exertions of better men than himself. John Stuart Mill. -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 07, 2004 2:35 PM To: Jakarta Commons Developers List Subject: Re: [lang] StringUtils.split ignores empty items (Bugzilla bug# 22692) of splitPreserveTokens and splitPreserveAllTokens I prefer the former, but am OK with the latter. Stephen - Original Message - From: Gary Gregory [EMAIL PROTECTED] So how about splitPreserveAllTokens. That might be a bit verbose, but it does convey exactly what the method does. Seems fine to me. Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] StringUtils.split ignores empty items (Bugzilla bug# 22692)
I'm sorry if my Gary doesn't like comment was offensive. It sure wasn't meant to be, just meant to state a fact and not make a value judgement. I actually feel the same way you do and cause my co-workers quite a bit of grief sometimes discussing the finer points of method naming. I was afraid I was making too much over the name, and am glad to know others feel it is important. edI am not making a big stink about this. My belief is that names are important, especially in a library. I like to discuss such things./ed Just to be more precise, what I am not fond of in splitVerb, as in splitPreserve, is that *what* is to be preserved is not specified and in my IMO not obvious, which is why I prefer, in the replacement of a boolean method (about which I am neutral), splitVerbObject, as in maybe splitKeepAllTokens. When I read code and I see splitKeepAllTokens (or something like it) I can pretty much guess (I think) what is going to happen. Now, you guys can tell that it is 100% obvious that the name splitPreserve describes an API that preserves all of the tokens (after all what else is there to preserve I wonder, but I do not have to wonder if you tell me in the name), in which case I'll happily believe you. My preference is too err on the side of verbosity and non-mysterious API names vs. brevity ;-) The C days are long gone :-) Gary -Original Message- From: Steven Caswell [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 06, 2004 16:51 To: 'Jakarta Commons Developers List' Subject: RE: [lang] StringUtils.split ignores empty items (Bugzilla bug# 22692) Gary didn't like splitPreserve. I originally suggested splitPreserve so that's fine by me. I could also go with splitAll. And I agree, I don't like the boolean flags either. Steven Caswell Sun Certified Java Programmer [EMAIL PROTECTED] War is an ugly thing, but not the ugliest of things. The decayed and degraded state of moral and patriotic feeling that thinks that nothing is worth war is much worse. The person who has nothing for which he is willing to fight, nothing which is more important than his own personal safety, is a miserable creature and has no chance of being free unless made and kept so by the exertions of better men than himself. John Stuart Mill. -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 06, 2004 6:28 PM To: Jakarta Commons Developers List Subject: Re: [lang] StringUtils.split ignores empty items (Bugzilla bug# 22692) StringUtils currently has no boolean flags in method args, and I want to keep it that way. splitAll? 'Split the string keeping All the tokens' splitPreserve? 'Split the string Preserving all the tokens' Stephen - Original Message - From: Steven Caswell [EMAIL PROTECTED] I agree the name is not great. I'm not sure the other suggestions convey the method behavior either. I typically don't like adding a boolean to change the behavior, but rather have a different method of similar name, but I can't think of a great name either. A few more suggestions: - splitIncludeEmptyTokens - splitKeepEmptyTokens - splitWithEmptyTokens I think I like splitIncludeEmptyTokens the best. But to not keep beating this one to death, if one of these is not suitable, let's just go with adding a boolean argument. Steven Caswell Sun Certified Java Programmer [EMAIL PROTECTED] War is an ugly thing, but not the ugliest of things. The decayed and degraded state of moral and patriotic feeling that thinks that nothing is worth war is much worse. The person who has nothing for which he is willing to fight, nothing which is more important than his own personal safety, is a miserable creature and has no chance of being free unless made and kept so by the exertions of better men than himself. John Stuart Mill. -Original Message- From: Gary Gregory [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 06, 2004 12:45 PM To: Jakarta Commons Developers List Subject: RE: [lang] StringUtils.split ignores empty items (Bugzilla bug# 22692) Indeed not a great name. splitPreserve does not tell you what it is preserving. How about: - Instead of splitPreserve, split with boolean argument. - Use another word: Keep or Include or With, with or without what is preserved: - splitKeep - splitKeepSeparator - splitWith - splitWithSeparator - splitInclude - splitIncludeSeparator ? Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Monday, July 05, 2004 15:43 To: Jakarta Commons Developers List Subject: Re: [lang] StringUtils.split ignores empty items (Bugzilla bug# 22692) Although splitPreserve
Re: [lang] DateUtils.parseCVS
That does make things a little clearer. Perhaps it should be it's own class, with a parse and a format method, a la SimpleDateFormat. Ahh. I like the yesterday etc part, but name definitely needs to change. Also I would want a formatter for it (somehow) so we can turn a Date into 'yesterday', '9 days ago' etc. Hen On Tue, 6 Jul 2004, Serge Knystautas wrote: Gary Gregory wrote: I am not that crazy with anything of the form parseProduct. What if there was, or surely going to be 2, then 10 such methods for CVS. Then a CvsUtils or some such class would be better. Does this belongs in a separate class if not in the sandbox? Sorry for not jumping into this thread earlier. The DateUtils is my submission, so I should probably explain parseCVS... It does NOT parse any dates from CVS, so it isn't related to ant or any other tool. From using CVS, you can checkout code as of yesterday, a week ago, or last Thursday. CVS parses this human date expression and calculates that date for you. That is the behavior I was trying to emulate... support a more human readable date parser. It's not a great name, but CVS was the language parsing rule I was based on. I've got no special urge to keep it in lang, if others do not want. -- Serge Knystautas Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
