[jira] Commented: (LANG-326) StringUtils: startsWith / endsWith / startsWithIgnoreCase / endsWithIgnoreCase / removeStartIgnoreCase / removeEndIgnoreCase methods
[ https://issues.apache.org/jira/browse/LANG-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489332 ] Stephen Colebourne commented on LANG-326: - Is there a role for CaseInsensitiveStringUtils instead? How many of these methods need adding? StringUtils: startsWith / endsWith / startsWithIgnoreCase / endsWithIgnoreCase / removeStartIgnoreCase / removeEndIgnoreCase methods Key: LANG-326 URL: https://issues.apache.org/jira/browse/LANG-326 Project: Commons Lang Issue Type: New Feature Affects Versions: 2.3 Reporter: Niall Pemberton Priority: Minor Fix For: 3.0 Attachments: LANG-326-Start-End-With-2.patch I'd like the following new start/end methods for StringUtils: startsWith - handles nulls endsWith - handles nulls startsWithIgnoreCase - handles nulls, case insensitive endsWithIgnoreCase - handles nulls, case insensitive removeStartIgnoreCase - handles nulls, case insensitive removeEndIgnoreCase - handles nulls, case insensitive -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r529523 - in /jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration: AbstractConfiguration.java DatabaseConfiguration.java
Author: ebourg
Date: Tue Apr 17 01:31:58 2007
New Revision: 529523
URL: http://svn.apache.org/viewvc?view=revrev=529523
Log:
Simplification of the method resolveContainerStore() in AbstractConfiguration
Deprecated getConnection() in DatabaseConfiguration
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DatabaseConfiguration.java
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java?view=diffrev=529523r1=529522r2=529523
==
---
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java
Tue Apr 17 01:31:58 2007
@@ -17,6 +17,7 @@
package org.apache.commons.configuration;
+import java.lang.reflect.Array;
import java.math.BigDecimal;
import java.math.BigInteger;
import java.util.ArrayList;
@@ -624,6 +625,8 @@
return props;
}
+
+
/**
* [EMAIL PROTECTED]
* @see PropertyConverter#toBoolean(Object)
@@ -1227,45 +1230,9 @@
List list = (List) value;
value = list.isEmpty() ? null : list.get(0);
}
-else if (value instanceof Object[])
-{
-Object[] array = (Object[]) value;
-value = array.length == 0 ? null : array[0];
-}
-else if (value instanceof boolean[])
-{
-boolean[] array = (boolean[]) value;
-value = array.length == 0 ? null : array[0] ? Boolean.TRUE :
Boolean.FALSE;
-}
-else if (value instanceof byte[])
-{
-byte[] array = (byte[]) value;
-value = array.length == 0 ? null : new Byte(array[0]);
-}
-else if (value instanceof short[])
-{
-short[] array = (short[]) value;
-value = array.length == 0 ? null : new Short(array[0]);
-}
-else if (value instanceof int[])
-{
-int[] array = (int[]) value;
-value = array.length == 0 ? null : new Integer(array[0]);
-}
-else if (value instanceof long[])
-{
-long[] array = (long[]) value;
-value = array.length == 0 ? null : new Long(array[0]);
-}
-else if (value instanceof float[])
-{
-float[] array = (float[]) value;
-value = array.length == 0 ? null : new Float(array[0]);
-}
-else if (value instanceof double[])
+else if (value.getClass().isArray() Array.getLength(value) 0)
{
-double[] array = (double[]) value;
-value = array.length == 0 ? null : new Double(array[0]);
+value = Array.get(value, 0);
}
}
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DatabaseConfiguration.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DatabaseConfiguration.java?view=diffrev=529523r1=529522r2=529523
==
---
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DatabaseConfiguration.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DatabaseConfiguration.java
Tue Apr 17 01:31:58 2007
@@ -560,8 +560,9 @@
* @return the codeConnection/code object to be used
* @throws SQLException if an error occurs
* @since 1.4
+ * @deprecated Use a custom datasource to change the connection used by
the class. To be removed in Commons Configuration 2.0
*/
-Connection getConnection() throws SQLException
+protected Connection getConnection() throws SQLException
{
return getDatasource().getConnection();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r529531 - in /jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration: AbstractConfiguration.java BaseConfiguration.java CompositeConfiguration.java SubsetConf
Author: ebourg
Date: Tue Apr 17 01:52:41 2007
New Revision: 529531
URL: http://svn.apache.org/viewvc?view=revrev=529531
Log:
Removed the useless @inheritDoc tags (when no info is added to the javadoc of
the super class)
Removed the abstract methods in AbstractConfiguration declared in the
Configuration interface and implemented in a subclass
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/BaseConfiguration.java
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/CompositeConfiguration.java
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/SubsetConfiguration.java
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java?view=diffrev=529531r1=529530r2=529531
==
---
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java
Tue Apr 17 01:52:41 2007
@@ -376,9 +376,6 @@
});
}
-/**
- * [EMAIL PROTECTED]
- */
public void addProperty(String key, Object value)
{
fireEvent(EVENT_ADD_PROPERTY, key, value, true);
@@ -454,27 +451,11 @@
return base; // just a dummy implementation
}
-/**
- * [EMAIL PROTECTED]
- */
public Configuration subset(String prefix)
{
return new SubsetConfiguration(this, prefix, .);
}
-/**
- * [EMAIL PROTECTED]
- */
-public abstract boolean isEmpty();
-
-/**
- * [EMAIL PROTECTED]
- */
-public abstract boolean containsKey(String key);
-
-/**
- * [EMAIL PROTECTED]
- */
public void setProperty(String key, Object value)
{
fireEvent(EVENT_SET_PROPERTY, key, value, true);
@@ -518,9 +499,6 @@
// override in sub classes
}
-/**
- * [EMAIL PROTECTED]
- */
public void clear()
{
fireEvent(EVENT_CLEAR, null, null, true);
@@ -547,14 +525,6 @@
fireEvent(EVENT_CLEAR, null, null, false);
}
-/**
- * [EMAIL PROTECTED]
- */
-public abstract Iterator getKeys();
-
-/**
- * [EMAIL PROTECTED]
- */
public Iterator getKeys(final String prefix)
{
return new FilterIterator(getKeys(), new Predicate()
@@ -567,9 +537,6 @@
});
}
-/**
- * [EMAIL PROTECTED]
- */
public Properties getProperties(String key)
{
return getProperties(key, null);
@@ -625,8 +592,6 @@
return props;
}
-
-
/**
* [EMAIL PROTECTED]
* @see PropertyConverter#toBoolean(Object)
@@ -686,9 +651,6 @@
}
}
-/**
- * [EMAIL PROTECTED]
- */
public byte getByte(String key)
{
Byte b = getByte(key, null);
@@ -702,17 +664,11 @@
}
}
-/**
- * [EMAIL PROTECTED]
- */
public byte getByte(String key, byte defaultValue)
{
return getByte(key, new Byte(defaultValue)).byteValue();
}
-/**
- * [EMAIL PROTECTED]
- */
public Byte getByte(String key, Byte defaultValue)
{
Object value = resolveContainerStore(key);
@@ -734,9 +690,6 @@
}
}
-/**
- * [EMAIL PROTECTED]
- */
public double getDouble(String key)
{
Double d = getDouble(key, null);
@@ -750,17 +703,11 @@
}
}
-/**
- * [EMAIL PROTECTED]
- */
public double getDouble(String key, double defaultValue)
{
return getDouble(key, new Double(defaultValue)).doubleValue();
}
-/**
- * [EMAIL PROTECTED]
- */
public Double getDouble(String key, Double defaultValue)
{
Object value = resolveContainerStore(key);
@@ -782,9 +729,6 @@
}
}
-/**
- * [EMAIL PROTECTED]
- */
public float getFloat(String key)
{
Float f = getFloat(key, null);
@@ -798,17 +742,11 @@
}
}
-/**
- * [EMAIL PROTECTED]
- */
public float getFloat(String key, float defaultValue)
{
return getFloat(key, new Float(defaultValue)).floatValue();
}
-/**
- * [EMAIL PROTECTED]
- */
public Float getFloat(String key, Float defaultValue)
{
Object value = resolveContainerStore(key);
@@ -830,9 +768,6 @@
}
}
-/**
- * [EMAIL PROTECTED]
- */
public int getInt(String key)
{
Integer i = getInteger(key, null);
@@
svn commit: r529550 - in /jakarta/commons/proper/configuration/trunk/src: java/org/apache/commons/configuration/DataConfiguration.java test/org/apache/commons/configuration/TestDataConfiguration.java
Author: ebourg
Date: Tue Apr 17 03:42:41 2007
New Revision: 529550
URL: http://svn.apache.org/viewvc?view=revrev=529550
Log:
Improved the test coverage for DataConfiguration by storing directly the arrays
in the configuration
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DataConfiguration.java
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestDataConfiguration.java
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DataConfiguration.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DataConfiguration.java?view=diffrev=529550r1=529549r2=529550
==
---
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DataConfiguration.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DataConfiguration.java
Tue Apr 17 03:42:41 2007
@@ -91,7 +91,14 @@
protected void addPropertyDirect(String key, Object obj)
{
-configuration.addProperty(key, obj);
+if (configuration instanceof AbstractConfiguration)
+{
+((AbstractConfiguration) configuration).addPropertyDirect(key,
obj);
+}
+else
+{
+configuration.addProperty(key, obj);
+}
}
public boolean isEmpty()
Modified:
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestDataConfiguration.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestDataConfiguration.java?view=diffrev=529550r1=529549r2=529550
==
---
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestDataConfiguration.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestDataConfiguration.java
Tue Apr 17 03:42:41 2007
@@ -54,8 +54,8 @@
conf.addProperty(boolean.list2, true, false);
conf.addProperty(boolean.list3, Boolean.TRUE);
conf.addProperty(boolean.list3, Boolean.FALSE);
-conf.addProperty(boolean.list4, new Boolean[] { Boolean.TRUE,
Boolean.FALSE });
-conf.addProperty(boolean.list5, new boolean[] { true, false });
+conf.addPropertyDirect(boolean.list4, new Boolean[] { Boolean.TRUE,
Boolean.FALSE });
+conf.addPropertyDirect(boolean.list5, new boolean[] { true, false });
List booleans = new ArrayList();
booleans.add(Boolean.TRUE);
booleans.add(Boolean.FALSE);
@@ -70,8 +70,8 @@
conf.addProperty(byte.list2, 1, 2);
conf.addProperty(byte.list3, new Byte(1));
conf.addProperty(byte.list3, new Byte(2));
-conf.addProperty(byte.list4, new Byte[] { new Byte(1), new
Byte(2) });
-conf.addProperty(byte.list5, new byte[] { 1, 2 });
+conf.addPropertyDirect(byte.list4, new Byte[] { new Byte(1), new
Byte(2) });
+conf.addPropertyDirect(byte.list5, new byte[] { 1, 2 });
List bytes = new ArrayList();
bytes.add(new Byte(1));
bytes.add(new Byte(2));
@@ -86,8 +86,8 @@
conf.addProperty(short.list2, 1, 2);
conf.addProperty(short.list3, new Short(1));
conf.addProperty(short.list3, new Short(2));
-conf.addProperty(short.list4, new Short[] { new Short(1), new
Short(2) });
-conf.addProperty(short.list5, new short[] { 1, 2 });
+conf.addPropertyDirect(short.list4, new Short[] { new Short(1),
new Short(2) });
+conf.addPropertyDirect(short.list5, new short[] { 1, 2 });
List shorts = new ArrayList();
shorts.add(new Short(1));
shorts.add(new Short(2));
@@ -102,8 +102,8 @@
conf.addProperty(integer.list2, 1, 2);
conf.addProperty(integer.list3, new Integer(1));
conf.addProperty(integer.list3, new Integer(2));
-conf.addProperty(integer.list4, new Integer[] { new Integer(1),
new Integer(2) });
-conf.addProperty(integer.list5, new int[] { 1, 2 });
+conf.addPropertyDirect(integer.list4, new Integer[] { new
Integer(1), new Integer(2) });
+conf.addPropertyDirect(integer.list5, new int[] { 1, 2 });
List integers = new ArrayList();
integers.add(new Integer(1));
integers.add(new Integer(2));
@@ -118,8 +118,8 @@
conf.addProperty(long.list2, 1, 2);
conf.addProperty(long.list3, new Long(1));
conf.addProperty(long.list3, new Long(2));
-conf.addProperty(long.list4, new Long[] { new Long(1), new
Long(2) });
-conf.addProperty(long.list5, new long[] { 1, 2 });
+conf.addPropertyDirect(long.list4, new Long[] { new
svn commit: r529564 - in /jakarta/commons/proper/configuration/trunk/src: java/org/apache/commons/configuration/AbstractConfiguration.java test/org/apache/commons/configuration/TestBaseConfiguration.j
Author: ebourg
Date: Tue Apr 17 04:09:43 2007
New Revision: 529564
URL: http://svn.apache.org/viewvc?view=revrev=529564
Log:
Changed resolveContainerStore() in AbstractConfiguration to return the first
element of a collection
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestBaseConfiguration.java
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java?view=diffrev=529564r1=529563r2=529564
==
---
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java
Tue Apr 17 04:09:43 2007
@@ -21,6 +21,7 @@
import java.math.BigDecimal;
import java.math.BigInteger;
import java.util.ArrayList;
+import java.util.Collection;
import java.util.Iterator;
import java.util.List;
import java.util.NoSuchElementException;
@@ -1112,21 +1113,21 @@
/**
* Returns an object from the store described by the key. If the value is a
- * List object, replace it with the first object in the list.
+ * Collection object, replace it with the first object in the collection.
*
* @param key The property key.
*
- * @return value Value, transparently resolving a possible List dependency.
+ * @return value Value, transparently resolving a possible collection
dependency.
*/
protected Object resolveContainerStore(String key)
{
Object value = getProperty(key);
if (value != null)
{
-if (value instanceof List)
+if (value instanceof Collection)
{
-List list = (List) value;
-value = list.isEmpty() ? null : list.get(0);
+Collection collection = (Collection) value;
+value = collection.isEmpty() ? null :
collection.iterator().next();
}
else if (value.getClass().isArray() Array.getLength(value) 0)
{
Modified:
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestBaseConfiguration.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestBaseConfiguration.java?view=diffrev=529564r1=529563r2=529564
==
---
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestBaseConfiguration.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestBaseConfiguration.java
Tue Apr 17 04:09:43 2007
@@ -26,8 +26,10 @@
import java.util.List;
import java.util.NoSuchElementException;
import java.util.Properties;
+import java.util.Set;
import java.util.StringTokenizer;
+import org.apache.commons.collections.set.ListOrderedSet;
import org.apache.commons.configuration.event.ConfigurationEvent;
import org.apache.commons.configuration.event.ConfigurationListener;
import org.apache.commons.configuration.interpol.ConfigurationInterpolator;
@@ -781,6 +783,14 @@
config.addPropertyDirect(list, list);
assertEquals(first element of the 'list' property, foo,
config.resolveContainerStore(list));
+
+// set of objects
+Set set = new ListOrderedSet();
+set.add(foo);
+set.add(bar);
+config.addPropertyDirect(set, set);
+
+assertEquals(first element of the 'set' property, foo,
config.resolveContainerStore(set));
// arrays of primitives
config.addPropertyDirect(array.boolean, new boolean[] { true, false
});
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[nightly build] configuration failed.
Failed build logs: http://vmbuild.apache.org/~commons/nightly/logs//20070417/configuration.log - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (COLLECTIONS-246) LoopingListIterator behaves unexpected on next and previous mixed
[
https://issues.apache.org/jira/browse/COLLECTIONS-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489419
]
Henri Yandell commented on COLLECTIONS-246:
---
Yeah, this one is interesting. In COLLECTIONS-239, the way it works is (afaik)
by design and so that one should be a WONTFIX.
In this case, I think the same kind of problem exists. The statement of 'here I
am on 0' in inaccurate, instead 'here' is the space between 0 and 1, not
one of the elements. If we think of things as existing at an element and not
the space between, then the example above begins pointing at 2, and in the
non looping case it begins pointing at a null value that is prior to the list.
That feels very odd.
I can see why these semantics don't give people what they want. Pointing at
elements, while confusing at the boundaries, does make more sense in their use
cases. I wonder if it would all be simpler if we didn't have the bad two-in-one
next() previous() methods but used getNext() and moveToNext() semantics.
LoopingListIterator behaves unexpected on next and previous mixed
-
Key: COLLECTIONS-246
URL: https://issues.apache.org/jira/browse/COLLECTIONS-246
Project: Commons Collections
Issue Type: Bug
Components: Iterator
Affects Versions: 3.2
Environment: JDK 1.4.2_12
Common Collections 3.2
Reporter: Frank Hefter
Priority: Blocker
Using ArrayList as the backing list.
This combination at least returns unexpected results as you can see in the
testcase below.
I used this for a list navigator in a web frontend and had trouble with users.
I suspect java.util.AbstrList$ListItr (role of cursor var seems to be wrong
implemented ) to cause this problem. If so maybe we have to implement it in a
different way.
Testcase (it runs without hassle but the comments show whats wrong):
---
import java.util.ArrayList;
import junit.framework.TestCase;
import org.apache.commons.collections.iterators.LoopingListIterator;
public class SelectionControllerTest extends TestCase {
public void testSelectorForApache() {
ArrayList al = new ArrayList();
al.add(0); al.add(1); al.add(2);
LoopingListIterator it = new LoopingListIterator(al);
assertEquals(0, it.next()); // This is OK
// here I am on 0
assertEquals(0, it.previous()); // Wrong ! This should be 2!
// here I am on 0 too! This is wrong.
assertEquals(2, it.previous());
assertEquals(1, it.previous());
assertEquals(0, it.previous());
assertEquals(2, it.previous());
// here I am on 2
assertEquals(2, it.next()); // Wrong ! This should be 0!
// here I am on 2 too! This is wrong.
assertEquals(0, it.next());
assertEquals(1, it.next());
// here I am on 1
assertEquals(1, it.previous()); // Wrong ! This should be 0!
}
}
---
Thanks for your help.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JXPATH-80) boolean conversion of javabean getter values returning NULL fails
[
https://issues.apache.org/jira/browse/JXPATH-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489449
]
Matt Benson commented on JXPATH-80:
---
Wow, this is a nice one. I understand what's happening; I don't claim that my
fundamental xpath knowledge is necessarily up to the task of deciding what to
do about it. I modified your testcase somewhat and find that you are correct.
JXPath has some substantially complex code, but the problem is linked to the
fact that a collection encountered in the object graph is like an invisible
node: the collection name refers collectively to its members. Thus, any
property that might hold a collection (e.g. one of type Object) is viewed as an
empty collection, so the null node one expects to be compared with false()
isn't found. Similarly, look at this example:
class Bean {
public Object getValue5() {
return new Object[] { foo, bar, null };
}
}
Here, both of the following xpaths are true--
bean/value5 = true()
bean/value5 = false()
--because both null and non-null values are found in the property value.
This seems somewhat nonsensical in the same way the original error does, but
I'm not sure how deep the changes to address this would be, nor am I sure
whether this is truly incorrect, or just strange. I will have to do further
research as I am able, and of course, input from any other quarter is welcome.
boolean conversion of javabean getter values returning NULL fails
-
Key: JXPATH-80
URL: https://issues.apache.org/jira/browse/JXPATH-80
Project: Commons JXPath
Issue Type: Bug
Affects Versions: 1.2 Final
Environment: java.runtime.name=Java(TM) SE Runtime Environment
java.runtime.version=1.6.0-b105
java.specification.name=Java Platform API Specification
java.specification.vendor=Sun Microsystems Inc.
java.vm.info=mixed mode
java.vm.name=Java HotSpot(TM) Client VM
Reporter: Nico Max
Priority: Minor
Attachments: test.java
According to the JXPath User Guide a Javabean Getter returning NULL,
regadless of the type, will be converted bo Boolean FALSE. But trying to
build a boolean expression from this fails as the attached testcase shows.
It seems that the type the bean getter returns matters, as a NULL String for
example works as expected.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r529598 - /jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestDataConfiguration.java
Author: ebourg
Date: Tue Apr 17 06:43:38 2007
New Revision: 529598
URL: http://svn.apache.org/viewvc?view=revrev=529598
Log:
More test coverage for DataConfiguration
Modified:
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestDataConfiguration.java
Modified:
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestDataConfiguration.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestDataConfiguration.java?view=diffrev=529598r1=529597r2=529598
==
---
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestDataConfiguration.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestDataConfiguration.java
Tue Apr 17 06:43:38 2007
@@ -17,7 +17,7 @@
package org.apache.commons.configuration;
-import java.awt.*;
+import java.awt.Color;
import java.math.BigDecimal;
import java.math.BigInteger;
import java.net.URL;
@@ -26,6 +26,7 @@
import java.util.ArrayList;
import java.util.Calendar;
import java.util.Date;
+import java.util.Iterator;
import java.util.List;
import java.util.Locale;
@@ -285,6 +286,51 @@
calendars.add(date2);
conf.addProperty(calendar.list6, calendars);
conf.addProperty(calendar.list.interpolated,
${calendar.string},2004-12-31);
+}
+
+public void testGetConfiguration()
+{
+Configuration baseconf = new BaseConfiguration();
+DataConfiguration conf = new DataConfiguration(baseconf);
+
+assertEquals(base configuration, baseconf, conf.getConfiguration());
+}
+
+public void testIsEmpty()
+{
+Configuration baseconf = new BaseConfiguration();
+DataConfiguration conf = new DataConfiguration(baseconf);
+
+assertTrue(not empty, conf.isEmpty());
+
+baseconf.setProperty(foo, bar);
+
+assertFalse(empty, conf.isEmpty());
+}
+
+public void testContainsKey()
+{
+Configuration baseconf = new BaseConfiguration();
+DataConfiguration conf = new DataConfiguration(baseconf);
+
+assertFalse(conf.containsKey(foo));
+
+baseconf.setProperty(foo, bar);
+
+assertTrue(conf.containsKey(foo));
+}
+
+public void testGetKeys()
+{
+Configuration baseconf = new BaseConfiguration();
+DataConfiguration conf = new DataConfiguration(baseconf);
+
+baseconf.setProperty(foo, bar);
+
+Iterator it = conf.getKeys();
+assertTrue(the iterator is empty, it.hasNext());
+assertEquals(unique key, foo, it.next());
+assertFalse(the iterator is not exhausted, it.hasNext());
}
public void testGetBooleanArray()
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] StringUtils startsWith / endsWith methods
I guess I'll hold off on commiting this for the time being - Stephen C. asked (on Jira ticket LANG-316) whether we should have a CaseInsenstiveStringUtils - and Stephen K's is also a good point (Collators were news to me). Niall On 4/17/07, Stephen Kestle [EMAIL PROTECTED] wrote: Yeah - ascii still does scale in some cases. However, I imagine String.equalsIgnoreCase() is an exercise in legacy code conversion as well as speed. By all means, add ignoreCase for the shops that don't need/know better, but just make sure that Collator/Comparator use is an option, and is encouraged in the javadoc. I'm not sure how to raise a ticket for this, as it probably spans quite a few classes... Henri Yandell wrote: Stephen Kestle had this view of case insensitivity: http://issues.apache.org/jira/browse/LANG-316 Given that I've a strong interest in multiple locales etc, I definitely see Stephen's point, but your example shows a good reason why the low ASCII chars do scale - domain names (at least until it all gets complicated at some unknown point in the future). Make them @since 3.0 (given that's what it is in JIRA). We can change that later if need be. Hen On 4/15/07, Niall Pemberton [EMAIL PROTECTED] wrote: I posted a patch for StringUtils to add a number of new methods to the following Jira ticket: http://issues.apache.org/jira/browse/LANG-326 Any objections to me committing this? Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r529683 - /jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/Digester.java
Author: bayard Date: Tue Apr 17 10:43:38 2007 New Revision: 529683 URL: http://svn.apache.org/viewvc?view=revrev=529683 Log: Fixing L - l typo in parameter name Modified: jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/Digester.java Modified: jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/Digester.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/Digester.java?view=diffrev=529683r1=529682r2=529683 == --- jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/Digester.java (original) +++ jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/Digester.java Tue Apr 17 10:43:38 2007 @@ -1813,7 +1813,7 @@ * Parse the content of the specified URL using this Digester. * Returns the root element from the object stack (if any). * - * @param urL URL containing the XML data to be parsed + * @param url URL containing the XML data to be parsed * * @exception IOException if an input/output error occurs * @exception SAXException if a parsing exception occurs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-326) StringUtils: startsWith / endsWith / startsWithIgnoreCase / endsWithIgnoreCase / removeStartIgnoreCase / removeEndIgnoreCase methods
[ https://issues.apache.org/jira/browse/LANG-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489469 ] Niall Pemberton commented on LANG-326: -- Theres already case-insensitive equals and contains - potentially theres a number of other candidates (e.g. indexOf, lastIndexOf, remove, replace) - but I don't haven't had a use for them so far. Stephen Kestle also raised the point that for other Locale case insensitivity should use a Collator - see http://tinyurl.com/3d2jjk and LANG-316. I guess for either CaseInsensitiveStringUtils or using Collators it needs someone willing to do the work. StringUtils: startsWith / endsWith / startsWithIgnoreCase / endsWithIgnoreCase / removeStartIgnoreCase / removeEndIgnoreCase methods Key: LANG-326 URL: https://issues.apache.org/jira/browse/LANG-326 Project: Commons Lang Issue Type: New Feature Affects Versions: 2.3 Reporter: Niall Pemberton Priority: Minor Fix For: 3.0 Attachments: LANG-326-Start-End-With-2.patch I'd like the following new start/end methods for StringUtils: startsWith - handles nulls endsWith - handles nulls startsWithIgnoreCase - handles nulls, case insensitive endsWithIgnoreCase - handles nulls, case insensitive removeStartIgnoreCase - handles nulls, case insensitive removeEndIgnoreCase - handles nulls, case insensitive -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r529734 - in /jakarta/commons/proper/configuration/trunk: conf/test.xml src/java/org/apache/commons/configuration/XMLConfiguration.java src/test/org/apache/commons/configuration/TestXMLCon
Author: oheger
Date: Tue Apr 17 12:49:51 2007
New Revision: 529734
URL: http://svn.apache.org/viewvc?view=revrev=529734
Log:
CONFIGURATION-263: Fix for problem with XMLConfiguration and attribute nodes
when list values are involved
Modified:
jakarta/commons/proper/configuration/trunk/conf/test.xml
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/XMLConfiguration.java
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestXMLConfiguration.java
jakarta/commons/proper/configuration/trunk/xdocs/changes.xml
Modified: jakarta/commons/proper/configuration/trunk/conf/test.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/conf/test.xml?view=diffrev=529734r1=529733r2=529734
==
--- jakarta/commons/proper/configuration/trunk/conf/test.xml (original)
+++ jakarta/commons/proper/configuration/trunk/conf/test.xml Tue Apr 17
12:49:51 2007
@@ -78,4 +78,11 @@
empty string as value.
--
empty/
+
+!-- List nodes with attributes --
+attrList
+ a name=xABC/a
+ a name=y1,2,3/a
+ a name=u,v,w test=yesvalue1,value2/a
+/attrList
/testconfig
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/XMLConfiguration.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/XMLConfiguration.java?view=diffrev=529734r1=529733r2=529734
==
---
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/XMLConfiguration.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/XMLConfiguration.java
Tue Apr 17 12:49:51 2007
@@ -477,12 +477,25 @@
if (values.size() 1)
{
-// remove the original child
+Iterator it = values.iterator();
+// Create new node for the original child's first value
+Node c = createNode(child.getName());
+c.setValue(it.next());
+// Copy original attributes to the new node
+for (Iterator itAttrs = child.getAttributes().iterator();
itAttrs
+.hasNext();)
+{
+Node ndAttr = (Node) itAttrs.next();
+ndAttr.setReference(null);
+c.addAttribute(ndAttr);
+}
parent.remove(child);
+parent.addChild(c);
+
// add multiple new children
-for (Iterator it = values.iterator(); it.hasNext();)
+while (it.hasNext())
{
-Node c = new XMLNode(child.getName(), null);
+c = new XMLNode(child.getName(), null);
c.setValue(it.next());
parent.addChild(c);
}
Modified:
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestXMLConfiguration.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestXMLConfiguration.java?view=diffrev=529734r1=529733r2=529734
==
---
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestXMLConfiguration.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestXMLConfiguration.java
Tue Apr 17 12:49:51 2007
@@ -963,6 +963,69 @@
}
/**
+ * Tests list nodes with multiple values and attributes.
+ */
+public void testListWithAttributes()
+{
+assertEquals(Wrong number of a elements, 6, conf.getList(
+attrList.a).size());
+assertEquals(Wrong value of first element, ABC, conf
+.getString(attrList.a(0)));
+assertEquals(Wrong value of first name attribute, x, conf
+.getString(attrList.a(0)[EMAIL PROTECTED]));
+assertEquals(Wrong number of name attributes, 5, conf.getList(
+[EMAIL PROTECTED]).size());
+}
+
+/**
+ * Tests a list node with attributes that has multiple values separated by
+ * the list delimiter. In this scenario the attribute should be added to
the
+ * node with the first value.
+ */
+public void testListWithAttributesMultiValue()
+{
+assertEquals(Wrong value of 2nd element, 1, conf
+.getString(attrList.a(1)));
+assertEquals(Wrong value of 2nd name attribute, y, conf
+.getString(attrList.a(1)[EMAIL PROTECTED]));
+for (int i = 2; i = 3; i++)
+{
+assertEquals(Wrong value of element
[jira] Resolved: (CONFIGURATION-263) XMLConfiguration drops attributes if a property value is a list
[
https://issues.apache.org/jira/browse/CONFIGURATION-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-263.
Resolution: Fixed
A fix was committed. In the problematic scenarios the attributes are now always
added to the first list node. So if there is a XML file like that:
...
list
a name=xtest1,test2/a
a name=y,z attr=u1,2,3/a
/list
the results are as following:
list
a name=xtest1/a
atest2/a
a name=y,z attr=u1/a
a2/a
a3/a
/list
XMLConfiguration drops attributes if a property value is a list
---
Key: CONFIGURATION-263
URL: https://issues.apache.org/jira/browse/CONFIGURATION-263
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.4
Reporter: Oliver Heger
Assigned To: Oliver Heger
Fix For: 1.5
When the following test is run with the following xml the second assertEquals
statement fails:
XML:
?xml version=1.0 encoding=ISO-8859-1 ?
test
a name=XABC/a
a name=Y1,2,3/a
/test
TEST:
public void testXMLConfig() throws Exception {
File file = new File(/xml/xmlConfigTest.xml);
XMLConfiguration xmlConfig = new XMLConfiguration(file);
xmlConfig.load();
assertEquals(X,xmlConfig.getProperty(a(0)[EMAIL PROTECTED]));
assertEquals(Y,xmlConfig.getProperty(a(1)[EMAIL PROTECTED]));
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r529805 - in /jakarta/commons/proper/jci/trunk/src/site: site.xml xdoc/faq.xml
Author: tcurdt Date: Tue Apr 17 16:46:08 2007 New Revision: 529805 URL: http://svn.apache.org/viewvc?view=revrev=529805 Log: rephrased a few o=paragraphs, fixed broken links Modified: jakarta/commons/proper/jci/trunk/src/site/site.xml jakarta/commons/proper/jci/trunk/src/site/xdoc/faq.xml Modified: jakarta/commons/proper/jci/trunk/src/site/site.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/jci/trunk/src/site/site.xml?view=diffrev=529805r1=529804r2=529805 == --- jakarta/commons/proper/jci/trunk/src/site/site.xml (original) +++ jakarta/commons/proper/jci/trunk/src/site/site.xml Tue Apr 17 16:46:08 2007 @@ -1,4 +1,4 @@ -?xml version=1.0 encoding=ISO-8859-1? +?xml version=1.0? project name=Jakarta Commons JCI bannerRight nameJakarta Commons JCI/name @@ -7,10 +7,10 @@ /bannerRight body menu name=Jakarta Commons JCI -item name=About href=index.html/ -item name=Usage href=usage.html/ -item name=FAQ href=faq.html/ -item name=Downloads href=downloads.html/ +item name=About href=http://jakarta.apache.org/commons/jci/index.html/ +item name=Usage href=http://jakarta.apache.org/commons/jci/usage.html/ +item name=FAQ href=http://jakarta.apache.org/commons/jci/faq.html/ +item name=Downloads href=http://jakarta.apache.org/commons/jci/downloads.html/ /menu menu ref=modules/ /body Modified: jakarta/commons/proper/jci/trunk/src/site/xdoc/faq.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/jci/trunk/src/site/xdoc/faq.xml?view=diffrev=529805r1=529804r2=529805 == --- jakarta/commons/proper/jci/trunk/src/site/xdoc/faq.xml (original) +++ jakarta/commons/proper/jci/trunk/src/site/xdoc/faq.xml Tue Apr 17 16:46:08 2007 @@ -7,11 +7,11 @@ body section name=FAQ subsection name=Isn't compiler support integrated with Java6 (JSR199)? -Yes, it is now. JSR199 that in the end brought the official java compiler tools -with Mustang had stalled for many years. This is how JCI was born. JCI provided -what was missing from the JDK. And it provides it also for earlier versions. -The main author of JCI has later joined the EG and will make sure there is also -a bridge to the JSR199 API. +Yes, it is now. JSR199 in the end brought the official java compiler tools that +now come with Mustang. Progress on this had stalled for many years. This is how +JCI was born. JCI provided what was missing from the JDK. And it still provides +it also for earlier versions. The main author of JCI has later on joined the EG +and will make sure there is a bridge to the JSR199 API. /subsection subsection name=Doesn't JSR199 already deprecate JCI? Well, as said before ...there are no backports so far. And if you give the @@ -20,15 +20,14 @@ /subsection subsection name=How well tested is the code? Well, there are a couple of projects out there using this code already for -quite some time in production. Drools and Cocoon to name just a few know Open +quite some time in production. Drools and Cocoon to name just a few well known Open Source projects. Code coverage is not bad at all ...but there still a few things on the TODO list and contributions are always welcome. /subsection subsection name=Will the ... compiler be supported? -There is always room for more. And if the compiler supports compilation to -java bytecode there is a good chance it can be added. There are currently -already a few candidates out there. But it all comes down to the need and -the time to implement. +There is always room for new implementations. And if the compiler supports compilation to +java bytecode, there is also a good chance it can be added. There are currently already a +few potential candidates out there. But it all comes down to the need and the time to implement. /subsection /section /body - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r529843 - /jakarta/commons/proper/jelly/trunk/jelly-tags/xmlunit/src/java/org/apache/commons/jelly/tags/xmlunit/AssertDocumentsEqualTag.java
Author: bodewig
Date: Tue Apr 17 20:09:39 2007
New Revision: 529843
URL: http://svn.apache.org/viewvc?view=revrev=529843
Log:
remove deprecated method invocation
Modified:
jakarta/commons/proper/jelly/trunk/jelly-tags/xmlunit/src/java/org/apache/commons/jelly/tags/xmlunit/AssertDocumentsEqualTag.java
Modified:
jakarta/commons/proper/jelly/trunk/jelly-tags/xmlunit/src/java/org/apache/commons/jelly/tags/xmlunit/AssertDocumentsEqualTag.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/jelly/trunk/jelly-tags/xmlunit/src/java/org/apache/commons/jelly/tags/xmlunit/AssertDocumentsEqualTag.java?view=diffrev=529843r1=529842r2=529843
==
---
jakarta/commons/proper/jelly/trunk/jelly-tags/xmlunit/src/java/org/apache/commons/jelly/tags/xmlunit/AssertDocumentsEqualTag.java
(original)
+++
jakarta/commons/proper/jelly/trunk/jelly-tags/xmlunit/src/java/org/apache/commons/jelly/tags/xmlunit/AssertDocumentsEqualTag.java
Tue Apr 17 20:09:39 2007
@@ -76,7 +76,7 @@
Diff delta = null;
try {
-delta = XMLUnit.compare(
+delta = new Diff(
expectedDocument.asXML(),
actualDocument.asXML());
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release commons jci RC1 as 1.0
On 4/16/07, Torsten Curdt [EMAIL PROTECTED] wrote: On 12.04.2007, at 19:56, Niall Pemberton wrote: On 4/12/07, Torsten Curdt [EMAIL PROTECTED] wrote: Niall, really appreciate our input! On 12.04.2007, at 06:22, Niall Pemberton wrote: 1) NOTICE / LICENSE The issue raised by Rahul about the missing NOTICE and LICENSE files gets a bit complex.They are not specified as a resource element in version 2 of the commons parent pom (which AFAIK would cause them to be included in all modules) because of a bug in the maven source plugin (MSOURCES-6) with resource elements in the base directory - so it has an antrun workaround which doesn't seem to have worked in this multi-module case. Grr We're still waiting for a release of that plugin so the workaround can be removed. One solution is to move these to jci/src/main/resources (which is the default resources location for maven) For every artifact you mean? It looks that way - projects like Shale have done that - but maybe one of the maven gurus can offer a better idea. Well, would have been nice if that wasn't required - but you already worked around it :) snip/ Usually I don't mind whether people use the older RC method or create the actual aritifacts to be distributed - but in this case theres too many things to forget in a multi-module release so I won't vote on a RC for JCI - only the actual artifacts. So you want really individual votes for each artifact? ...keep in mind there is only one site though. Sorry, didn't say that very well. What I meant was rather than producing release candidate artifacts (i.e with version 1.0-RC1 numbers) - I'd rather vote on the actual artifacts that are going to be deployed if the votes passes - i.e. with the proper 1.0 version number. Ah! OK A number of components have done this recently and it means less chance of something going wrong after the vote passes as it simply becomes a case of copying the jars/distros that have been voted on rather than building a whole new set when cutting a release. True and makes total sense. Unfortunately the maven release process does not really adhere to that - unless I am missing something. mvn release:prepare -Prc mvn release:perform -Prc Creates the tag and deploy to the snapshot repo. mvn release:prepare -Prelease mvn release:perform -Prelease Would be next but that would not match our (or the quite common) process of turning a RC into a release. AIU projects using m2 that vote on actual release artifacts use a staging repository - but I guess that would take a change in the commons pom first. Anyway ignore my comment - I've not done a release using m2 and I guess if you resolve the reason why the release plugin didn't correctly update all the dependency versions for the RC then it should be OK. 3) Source/Binary distros Any reason not to produce the usual source/binary distros for JCI - rather than just maven artifacts? Well, how much different would that be? We could zip up artifacts but e.g. the site does not work offline (stupid!) unless you do a site:stage. Any suggestions? Site doesn't need to be included IMO - but a binary distro with all the JCI jars and javadocs would be nice and a source distro which is just a zip of the whole src repo. If I get time later I could add an assembly to create these. Thanks for that! 5) site.xml Seems that all the modules are using the parent site.xml, since they don't have one - which means all the module sites have a Usage, FAQ and Downloads links which are broken. You probably need to include site.xml for each module to avoid this. As the site.xml is inherited I would assume the links get adjusted. That sucks! How stupid is that? True and probably doesn't matter for the release since you're not shipping that. So perhaps something to ponder after. Well, would love to have a working site. Release or not ;) Stupid maven multiproject stuff. cheers -- Torsten - 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: [vote] release commons jci RC1 as 1.0
Couple more comments (sorry been digging around in the source code) - the main issue IMO is deprecations 1) Deprecations A number of classes have deprecations - I think these should be removed prior to the first release of JCI: JavaCompilerFactory - static instance ( accessor method) is deprecated FileResourceReader - list() methods deprecated MemoryResourceReader - list() method deprecated FileResourceStore - list() methods deprecated MemoryResourceStore - list() method deprecated 2) ConversionUtils - The toJavaCasing() method is only used by JavaCompilerFactory - perhaps should be a private method in JavaCompilerFactory? - The clazzName() method is not used - should be removed? 3) Commons IO Dependency The Commons IO dependency is only used by 3 classes (ReloadingListener, FileResourceReader and FileResourceStore) and only needs two IOUitls methods - toByteArray() and closeQuietly() (FileResourceReader uses FileUtils but I think it could also use IOUitls.toByteArray() instead). Wouldn't it be better to copy these 2 methods and remove the need for the Commons IO dependency? If this isn't considered a good idea then theres a couple of methods in ConversionUtils that could be replaced by Commons IO: ConversionUtils.stripExtension() -- FilenameUtils.removeExtension() ConversionUtils.getResourceNameFromFileName() -- FilenameUtils.separatorsToUnix() 4) EclipseJavaCompilerSettings The (package friendly) getMap() method of EclipseJavaCompilerSettings overrides/fixes four of the settings in the Map - including setting the source/target version at 1.4 - just wondering why and is this correct? Niall On 4/11/07, Torsten Curdt [EMAIL PROTECTED] wrote: Since RC1 is working fine for cocoon and other parties I would like to call a vote on the release for commons jci. http://jakarta.apache.org/commons/jci/ http://people.apache.org/repo/m2-snapshot-repository/org/apache/ commons/commons-jci/1.0-RC1/ http://people.apache.org/repo/m2-snapshot-repository/org/apache/ commons/commons-jci-core/1.0-RC1/ http://people.apache.org/repo/m2-snapshot-repository/org/apache/ commons/commons-jci-eclipse/1.0-RC1/ http://people.apache.org/repo/m2-snapshot-repository/org/apache/ commons/commons-jci-fam/1.0-RC1/ http://people.apache.org/repo/m2-snapshot-repository/org/apache/ commons/commons-jci-groovy/1.0-RC1/ http://people.apache.org/repo/m2-snapshot-repository/org/apache/ commons/commons-jci-janino/1.0-RC1/ http://people.apache.org/repo/m2-snapshot-repository/org/apache/ commons/commons-jci-javac/1.0-RC1/ http://people.apache.org/repo/m2-snapshot-repository/org/apache/ commons/commons-jci-rhino/1.0-RC1/ Please cast your votes. cheers -- Torsten - 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: [vote] release commons jci RC1 as 1.0
On 4/15/07, Torsten Curdt [EMAIL PROTECTED] wrote: Niall wrote: A number of components have done this recently and it means less chance of something going wrong after the vote passes as it simply becomes a case of copying the jars/distros that have been voted on rather than building a whole new set when cutting a release. True and makes total sense. Unfortunately the maven release process does not really adhere to that - unless I am missing something. mvn release:prepare -Prc mvn release:perform -Prc Creates the tag and deploy to the snapshot repo. mvn release:prepare -Prelease mvn release:perform -Prelease Would be next but that would not match our (or the quite common) process of turning a RC into a release. Instead of deploying straight to m2-ibiblio-rsync-repository, stage the release somewhere else for the vote. The two ways that work right now are: 1. Use an alternate deployment repository configured in the pom or on the command line. See http://maven.apache.org/developers/release/releasing.html which talks about how to release parts of the Maven project. 2. Override distributionManagementrepository in your project pom. Many projects use space under http://people.apache.org/builds/ to do this, for example: http://people.apache.org/builds/tiles/2.0.3/ . This has the source and binary distributions at the top, and then a staging repo for the Maven artifacts, which can be merged (or just copied) into the rsynced repo after the vote. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
