svn commit: r529919 - in /jakarta/commons/proper/configuration/trunk: src/java/org/apache/commons/configuration/ src/test/org/apache/commons/configuration/ xdocs/

2007-04-18 Thread ebourg
Author: ebourg
Date: Wed Apr 18 01:45:48 2007
New Revision: 529919

URL: http://svn.apache.org/viewvc?view=revrev=529919
Log:
DataConfiguration now supports the InetAddress type

Modified:

jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DataConfiguration.java

jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/PropertyConverter.java

jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestDataConfiguration.java
jakarta/commons/proper/configuration/trunk/xdocs/changes.xml

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=529919r1=529918r2=529919
==
--- 
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
 Wed Apr 18 01:45:48 2007
@@ -37,8 +37,8 @@
 
 /**
  * Decorator providing additional getters for any Configuration. This extended
- * Configuration supports more types: URL, Locale, Date, Calendar, Color, as
- * well as lists and arrays for all types.
+ * Configuration supports more types: URL, Locale, Date, Calendar, Color,
+ * InetAddress, as well as lists and arrays for all types.
  *
  * h4Example/h4
  *
@@ -46,6 +46,7 @@
  * pre
  * title.color = #FF
  * default.locales = fr,en,de
+ * remote.host = 192.168.0.53
  * /pre
  *
  * Usage:
@@ -58,6 +59,7 @@
  *
  * // retrieve a property using a generic getter
  * Locale[] locales = (Locale[]) config.getArray(Locale.class, 
default.locales);
+ * InetAddress host = (InetAddress) config.get(InetAddress.class, 
remote.host);
  * /pre
  *
  * h4Dates/h4

Modified: 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/PropertyConverter.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/PropertyConverter.java?view=diffrev=529919r1=529918r2=529919
==
--- 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/PropertyConverter.java
 (original)
+++ 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/PropertyConverter.java
 Wed Apr 18 01:45:48 2007
@@ -20,10 +20,13 @@
 import java.awt.Color;
 import java.lang.reflect.Constructor;
 import java.lang.reflect.InvocationTargetException;
+import java.lang.reflect.Method;
 import java.math.BigDecimal;
 import java.math.BigInteger;
 import java.net.MalformedURLException;
 import java.net.URL;
+import java.net.InetAddress;
+import java.net.UnknownHostException;
 import java.text.ParseException;
 import java.text.SimpleDateFormat;
 import java.util.ArrayList;
@@ -39,6 +42,7 @@
 import org.apache.commons.collections.iterators.SingletonIterator;
 import org.apache.commons.lang.BooleanUtils;
 import org.apache.commons.lang.StringUtils;
+import org.apache.commons.lang.SystemUtils;
 
 /**
  * A utility class to convert the configuration properties into any type.
@@ -145,6 +149,10 @@
 {
 return PropertyConverter.toColor(value);
 }
+else if (InetAddress.class.isAssignableFrom(cls))
+{
+return PropertyConverter.toInetAddress(value);
+}
 
 throw new ConversionException(The value ' + value + ' ( + 
value.getClass() + ) can't be converted to a  + cls.getName() +  object);
 }
@@ -608,6 +616,38 @@
 else
 {
 throw new ConversionException(The value  + value +  can't be 
converted to a Color);
+}
+}
+
+/**
+ * Convert the specified value into an internet address.
+ *
+ * @param value the value to convert
+ * @return the converted value
+ * @throws ConversionException thrown if the value cannot be converted to 
a InetAddress
+ *
+ * @since 1.5
+ */
+static InetAddress toInetAddress(Object value) throws ConversionException
+{
+if (value instanceof InetAddress)
+{
+return (InetAddress) value;
+}
+else if (value instanceof String)
+{
+try
+{
+return InetAddress.getByName((String) value);
+}
+catch (UnknownHostException e)
+{
+throw new ConversionException(The value  + value +  can't 
be converted to a InetAddress, e);
+}
+}
+else
+{
+throw new ConversionException(The value  + value +  can't be 
converted to a InetAddress);
 }
 }
 

Modified: 

svn commit: r529948 - in /jakarta/commons/proper/configuration/trunk: ./ src/java/org/apache/commons/configuration/ src/test/org/apache/commons/configuration/ xdocs/

2007-04-18 Thread ebourg
Author: ebourg
Date: Wed Apr 18 03:09:35 2007
New Revision: 529948

URL: http://svn.apache.org/viewvc?view=revrev=529948
Log:
DataConfiguration now supports the javax.mail.internet.InternetAddress type for 
email adresses

Modified:
jakarta/commons/proper/configuration/trunk/project.xml

jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DataConfiguration.java

jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/PropertyConverter.java

jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestDataConfiguration.java
jakarta/commons/proper/configuration/trunk/xdocs/changes.xml

Modified: jakarta/commons/proper/configuration/trunk/project.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/project.xml?view=diffrev=529948r1=529947r2=529948
==
--- jakarta/commons/proper/configuration/trunk/project.xml (original)
+++ jakarta/commons/proper/configuration/trunk/project.xml Wed Apr 18 03:09:35 
2007
@@ -333,6 +333,16 @@
   /properties
 /dependency
 
+dependency
+  groupIdjavax.mail/groupId
+  artifactIdmail/artifactId
+  version1.4/version
+  urlhttp://java.sun.com/products/javamail//url
+  properties
+optionaltrue/optional
+  /properties
+/dependency
+
 !-- Needed for testing --
 
 dependency

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=529948r1=529947r2=529948
==
--- 
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
 Wed Apr 18 03:09:35 2007
@@ -37,16 +37,27 @@
 
 /**
  * Decorator providing additional getters for any Configuration. This extended
- * Configuration supports more types: URL, Locale, Date, Calendar, Color,
- * InetAddress, as well as lists and arrays for all types.
+ * Configuration supports more types:
+ * ul
+ *   li[EMAIL PROTECTED] java.net.URL}/li
+ *   li[EMAIL PROTECTED] java.util.Locale}/li
+ *   li[EMAIL PROTECTED] java.util.Date}/li
+ *   li[EMAIL PROTECTED] java.util.Calendar}/li
+ *   li[EMAIL PROTECTED] java.awt.Color}/li
+ *   li[EMAIL PROTECTED] java.net.InetAddress}/li
+ *   li[EMAIL PROTECTED] javax.mail.internet.InternetAddress} (requires 
Javamail in the classpath)/li
+ * /ul
+ *
+ * Lists and arrays are available for all types.
  *
  * h4Example/h4
  *
  * Configuration file ttconfig.properties/tt:
  * pre
  * title.color = #FF
- * default.locales = fr,en,de
  * remote.host = 192.168.0.53
+ * default.locales = fr,en,de
+ * email.contact = [EMAIL PROTECTED], [EMAIL PROTECTED]
  * /pre
  *
  * Usage:
@@ -58,8 +69,9 @@
  * Color color = config.getColor(title.color);
  *
  * // retrieve a property using a generic getter
- * Locale[] locales = (Locale[]) config.getArray(Locale.class, 
default.locales);
  * InetAddress host = (InetAddress) config.get(InetAddress.class, 
remote.host);
+ * Locale[] locales = (Locale[]) config.getArray(Locale.class, 
default.locales);
+ * List contacts = config.getList(InternetAddress.class, email.contact);
  * /pre
  *
  * h4Dates/h4

Modified: 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/PropertyConverter.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/PropertyConverter.java?view=diffrev=529948r1=529947r2=529948
==
--- 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/PropertyConverter.java
 (original)
+++ 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/PropertyConverter.java
 Wed Apr 18 03:09:35 2007
@@ -20,12 +20,11 @@
 import java.awt.Color;
 import java.lang.reflect.Constructor;
 import java.lang.reflect.InvocationTargetException;
-import java.lang.reflect.Method;
 import java.math.BigDecimal;
 import java.math.BigInteger;
+import java.net.InetAddress;
 import java.net.MalformedURLException;
 import java.net.URL;
-import java.net.InetAddress;
 import java.net.UnknownHostException;
 import java.text.ParseException;
 import java.text.SimpleDateFormat;
@@ -42,7 +41,6 @@
 import org.apache.commons.collections.iterators.SingletonIterator;
 import org.apache.commons.lang.BooleanUtils;
 import org.apache.commons.lang.StringUtils;
-import org.apache.commons.lang.SystemUtils;
 
 /**
  * A utility class to convert the configuration 

[nightly build] configuration failed.

2007-04-18 Thread Phil Steitz
Failed build logs:
http://vmbuild.apache.org/~commons/nightly/logs//20070418/configuration.log

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Created: (NET-158) login in FTPClient does not always read the complete server response

2007-04-18 Thread Gilles Gaillard (JIRA)
login in FTPClient does not always read the complete server response


 Key: NET-158
 URL: https://issues.apache.org/jira/browse/NET-158
 Project: Commons Net
  Issue Type: Bug
Affects Versions: 1.4
Reporter: Gilles Gaillard
Priority: Trivial


When a password is require to connect the FTP server, the implementation of 
method login in class FTPClient ends with:
  return FTPReply.isPositiveCompletion(pass(password))
which returns false for any code = 300.

However, some servers send a code 451 before returning the code 530 
(NOT_LOGGED_IN). Ignoring this addtional answer,
leads to desynch the client with the server, hence leading to unexpected 
behaviors in next exchanges.

Threfore i propose to replace the above code in the end of the method with:

  _replyCode = p_Client.pass(p_Password);
  boolean result = FTPReply.isPositiveCompletion(_replyCode);
  if (!result  _replyCode==FTPReply.ACTION_ABORTED){
try {
  _replyCode = p_Client.getReply();
} catch (Exception e){
  e.printStackTrace();
}
  }
  return result;


-- 
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] Updated: (NET-158) login in FTPClient does not always read the complete server response

2007-04-18 Thread Gilles Gaillard (JIRA)

 [ 
https://issues.apache.org/jira/browse/NET-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gilles Gaillard updated NET-158:


Description: 
When a password is required to connect the FTP server, the implementation of 
method login in class FTPClient ends with:
  return FTPReply.isPositiveCompletion(pass(password))
which returns false for any code = 300.

However, some servers send a code 451 before returning the code 530 
(NOT_LOGGED_IN). Ignoring this addtional answer,
leads to desynch the client with the server, hence leading to unexpected 
behaviors in next exchanges.

Threfore i propose to replace the above code in the end of the method with:

  _replyCode = p_Client.pass(p_Password);
  boolean result = FTPReply.isPositiveCompletion(_replyCode);
  if (!result  _replyCode==FTPReply.ACTION_ABORTED){
try {
  _replyCode = p_Client.getReply();
} catch (Exception e){
  e.printStackTrace();
}
  }
  return result;


  was:
When a password is require to connect the FTP server, the implementation of 
method login in class FTPClient ends with:
  return FTPReply.isPositiveCompletion(pass(password))
which returns false for any code = 300.

However, some servers send a code 451 before returning the code 530 
(NOT_LOGGED_IN). Ignoring this addtional answer,
leads to desynch the client with the server, hence leading to unexpected 
behaviors in next exchanges.

Threfore i propose to replace the above code in the end of the method with:

  _replyCode = p_Client.pass(p_Password);
  boolean result = FTPReply.isPositiveCompletion(_replyCode);
  if (!result  _replyCode==FTPReply.ACTION_ABORTED){
try {
  _replyCode = p_Client.getReply();
} catch (Exception e){
  e.printStackTrace();
}
  }
  return result;



 login in FTPClient does not always read the complete server response
 

 Key: NET-158
 URL: https://issues.apache.org/jira/browse/NET-158
 Project: Commons Net
  Issue Type: Bug
Affects Versions: 1.4
Reporter: Gilles Gaillard
Priority: Trivial

 When a password is required to connect the FTP server, the implementation of 
 method login in class FTPClient ends with:
   return FTPReply.isPositiveCompletion(pass(password))
 which returns false for any code = 300.
 However, some servers send a code 451 before returning the code 530 
 (NOT_LOGGED_IN). Ignoring this addtional answer,
 leads to desynch the client with the server, hence leading to unexpected 
 behaviors in next exchanges.
 Threfore i propose to replace the above code in the end of the method with:
   _replyCode = p_Client.pass(p_Password);
   boolean result = FTPReply.isPositiveCompletion(_replyCode);
   if (!result  _replyCode==FTPReply.ACTION_ABORTED){
 try {
   _replyCode = p_Client.getReply();
 } catch (Exception e){
   e.printStackTrace();
 }
   }
   return result;

-- 
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] Created: (VFS-126) Implementation of compareTo in FileSystemOptions.FileSystemOptionKey

2007-04-18 Thread Gilles Gaillard (JIRA)
Implementation of compareTo in FileSystemOptions.FileSystemOptionKey


 Key: VFS-126
 URL: https://issues.apache.org/jira/browse/VFS-126
 Project: Commons VFS
  Issue Type: Bug
Reporter: Gilles Gaillard
Priority: Trivial


Implementation of methof FileSystemOptions.FileSystemOptionKey.compareTo is:
public int compareTo(Object o)
{
FileSystemOptionKey k = (FileSystemOptionKey) o;
int ret = 
k.fileSystemClass.getName().compareTo(k.fileSystemClass.getName());
if (ret != 0)
{
return ret;
}
return name.compareTo(k.name);
}
It looks like if there is a typo and the ret value should be:
int ret = 
fileSystemClass.getName().compareTo(k.fileSystemClass.getName());


-- 
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: r529984 - /jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestDataConfiguration.java

2007-04-18 Thread ebourg
Author: ebourg
Date: Wed Apr 18 04:22:53 2007
New Revision: 529984

URL: http://svn.apache.org/viewvc?view=revrev=529984
Log:
Fixed the test case 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=529984r1=529983r2=529984
==
--- 
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
 Wed Apr 18 04:22:53 2007
@@ -1678,7 +1678,7 @@
 // interpolated value
 assertEquals(expected, conf.get(InetAddress.class, 
ip.string.interpolated));
 
-conf.setProperty(ip.unknownhost, 123);
+conf.setProperty(ip.unknownhost, foo);
 try
 {
 conf.get(InetAddress.class, ip.unknownhost);



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Commented: (NET-158) login in FTPClient does not always read the complete server response

2007-04-18 Thread Rory Winston (JIRA)

[ 
https://issues.apache.org/jira/browse/NET-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489702
 ] 

Rory Winston commented on NET-158:
--

HI Gilles

Thanks for the submission. What FTP server (version, OS ) is this happening 
with? Would you be able to include a trace of the server/client conversation 
(by using the PrintCommandListener) e.g.

client.addProtocolCommandListener(new PrintCommandListener(new
PrintWriter(System.out)));

Thanks,
Rory



 login in FTPClient does not always read the complete server response
 

 Key: NET-158
 URL: https://issues.apache.org/jira/browse/NET-158
 Project: Commons Net
  Issue Type: Bug
Affects Versions: 1.4
Reporter: Gilles Gaillard
Priority: Trivial

 When a password is required to connect the FTP server, the implementation of 
 method login in class FTPClient ends with:
   return FTPReply.isPositiveCompletion(pass(password))
 which returns false for any code = 300.
 However, some servers send a code 451 before returning the code 530 
 (NOT_LOGGED_IN). Ignoring this addtional answer,
 leads to desynch the client with the server, hence leading to unexpected 
 behaviors in next exchanges.
 Threfore i propose to replace the above code in the end of the method with:
   _replyCode = p_Client.pass(p_Password);
   boolean result = FTPReply.isPositiveCompletion(_replyCode);
   if (!result  _replyCode==FTPReply.ACTION_ABORTED){
 try {
   _replyCode = p_Client.getReply();
 } catch (Exception e){
   e.printStackTrace();
 }
   }
   return result;

-- 
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]



Re: [configuration] Re: [nightly build] configuration failed.

2007-04-18 Thread Emmanuel Bourg
I did a fresh install of Maven 1.0.2 on people.apache.org (FreeBSD 6.1, 
Java 5u7), with a fresh checkout of the code, and ran 'maven site'. The 
build failed on checkstyle with this error :


Unable to create a Checker: cannot initialize module TreeWalker - 
Property 'allowMissingJavadoc' in module JavadocMethod does not exist, 
please check the documentation


I had the same issue on my laptop, this property exists in the 
checkstyle documentation though. I removed the offending line and 
restarted the site generation, it completed normally.


Now I wonder why Phil's nightly builds report an xdoc error and not the 
checkstyle error. What command is used to start the nightly build ?


Emmanuel Bourg




Emmanuel Bourg a écrit :
I have the same version of Maven and the build works fine with the xdoc 
plugin 1.8. What is wrong ?


Emmanuel Bourg


Phil Steitz a écrit :

Failed build logs:
http://vmbuild.apache.org/~commons/nightly/logs//20070415/configuration.log 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Commented: (CONFIGURATION-264) SubnodeConfiguration does not see reloads of its parent configuration

2007-04-18 Thread Oliver Heger (JIRA)

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489707
 ] 

Oliver Heger commented on CONFIGURATION-264:


To make a SubnodeConfiguration compatible with reloads of its parent 
configuration two things need to be changed:

- An access of the subnode configuration needs to trigger the parent 
configuration, so that it can check if a reload is required.
- When the parent configuration is reloaded, its set of nodes is completely 
replaced. So the subnode configuration has to be reconstructed.

To achieve this, it is necessary to store in the subnode configuration the 
expression that was used to construct it. Then, when the subnode 
configuration's root node is queried (which happens for every property access), 
the parent can be asked to re-evaluate the expression and return the new root 
node. This will also trigger a reload of the parent if necessary.

This solution has the following drawbacks:
- It impacts the performance of SubnodeConfiguration because for each property 
access an additional query has to be performed on the parent.
- If the expression engine is changed on the parent configuration, we are lost.
- Some updates of the parent configuration may cause unexpected results. As an 
example consider that the parent configuration contains a list of properties 
and the subnode configuration points to a single element of this list. If now a 
list element before this element is removed, the subnode configuration will 
point to a different list element when it is reconstructed. This is because the 
expression the subnode configuration is based on cannot be updated according to 
changes on the parent's properties.
- The parent configuration could be changed in a way that the subnode 
configuration becomes invalid (e.g. if the root node of the subnode 
configuration is removed).

Because of these drawbacks I would like to make this solution optional: I would 
add a new configurationAt() method to HierarchicalConfiguration that takes an 
additional boolean argument. If this flag is set to true, the subnode 
configuration will do the described checks and thus will be aware of reloads of 
its parent. Otherwise (which is the default) the subnode configuration will 
behave as it does now (and miss the reloads).

 SubnodeConfiguration does not see reloads of its parent configuration
 -

 Key: CONFIGURATION-264
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-264
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.4
Reporter: Oliver Heger
 Assigned To: Oliver Heger
 Fix For: 1.5


 The problem can be reproduced as follows:
 1 config = new XMLConfiguration(c:\\conf.xml);
 2 config.setReloadingStrategy(new FileChangedReloadingStrategy());
 3 SubnodeConfiguration parentItemConfig = 
 config.configurationAt(parent-item);
 4 String ss2 = parentItemConfig.getString(sub-item);
 5 //Now, sub-item node value changes to new_value
 6 ss2 = parentItemConfig.getString(sub-item); // still returns old_value

-- 
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]



Re: [configuration] Re: [nightly build] configuration failed.

2007-04-18 Thread Niall Pemberton

On 4/18/07, Emmanuel Bourg [EMAIL PROTECTED] wrote:

I did a fresh install of Maven 1.0.2 on people.apache.org (FreeBSD 6.1,
Java 5u7), with a fresh checkout of the code, and ran 'maven site'. The
build failed on checkstyle with this error :

Unable to create a Checker: cannot initialize module TreeWalker -
Property 'allowMissingJavadoc' in module JavadocMethod does not exist,
please check the documentation

I had the same issue on my laptop, this property exists in the
checkstyle documentation though. I removed the offending line and
restarted the site generation, it completed normally.


I had the same issue when checking about RC3 - just needed to install
the latest checkstyle plugin for maven to resolve this:

http://tinyurl.com/ypcuy7


Now I wonder why Phil's nightly builds report an xdoc error and not the
checkstyle error. What command is used to start the nightly build ?


Maybe not related to the checkstyle issue? From memory we got the kind
of error the nightly build is seeing when the commons-build jsl script
was updated and specifying the xdoc plugin as 1.9.2 resolved it. Now
we no longer depend on commons-build - but my guess is its an isssue
with the combination of plugins /scripts installed on the nightly
build m/c. I know you revereted the plugin version from 1.9.2 back to
1.8 because of the title style - but since its breaking the nightly
build for configuration (and its the style most components use)
perhaps you should just switch back to the 1.9.2 version (or move to
m2)?

Niall


Emmanuel Bourg

Emmanuel Bourg a écrit :
 I have the same version of Maven and the build works fine with the xdoc
 plugin 1.8. What is wrong ?

 Emmanuel Bourg


 Phil Steitz a écrit :
 Failed build logs:
 http://vmbuild.apache.org/~commons/nightly/logs//20070415/configuration.log


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



svn commit: r530018 - /jakarta/commons/trunks-proper/

2007-04-18 Thread niallp
Author: niallp
Date: Wed Apr 18 06:42:36 2007
New Revision: 530018

URL: http://svn.apache.org/viewvc?view=revrev=530018
Log:
Add jci to externals

Modified:
jakarta/commons/trunks-proper/   (props changed)

Propchange: jakarta/commons/trunks-proper/
--
--- svn:externals (original)
+++ svn:externals Wed Apr 18 06:42:36 2007
@@ -22,6 +22,7 @@
 fileupload 
https://svn.apache.org/repos/asf/jakarta/commons/proper/fileupload/trunk
 httpclient 
https://svn.apache.org/repos/asf/jakarta/commons/proper/httpclient/trunk
 io https://svn.apache.org/repos/asf/jakarta/commons/proper/io/trunk
+jci https://svn.apache.org/repos/asf/jakarta/commons/proper/jci/trunk
 jelly https://svn.apache.org/repos/asf/jakarta/commons/proper/jelly/trunk
 jexl https://svn.apache.org/repos/asf/jakarta/commons/proper/jexl/trunk
 jxpath https://svn.apache.org/repos/asf/jakarta/commons/proper/jxpath/trunk



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Commented: (NET-158) login in FTPClient does not always read the complete server response

2007-04-18 Thread Gilles Gaillard (JIRA)

[ 
https://issues.apache.org/jira/browse/NET-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489735
 ] 

Gilles Gaillard commented on NET-158:
-

Hi Rory
here is a trace of the conversation:

Status: Connecting to perso-ftp.or.fr ...
Status: Connected with perso-ftp.or.fr. Waiting for welcome message...
Response:   220 or FTP server
Command:USER 
Response:   331 Password required for .
Command:PASS 
Response:   451 Pour transférer vos pages HTML sur le serveur or, vous 
devrez  etc..
Response:   530 Login incorrect.
Error:  Unable to connect!

After connecting, responses for SYST and FEAT:

Command:SYST
Response:   215 UNIX Type: L8
Command:FEAT
Response:   211-Features:
Response:   211-MDTM
Response:   211-REST STREAM
Response:   211-SIZE
Response:   211 End

I have implemented the change that i proposed and it works with all servers i 
tried (this one, Filezilla server, iis)


 login in FTPClient does not always read the complete server response
 

 Key: NET-158
 URL: https://issues.apache.org/jira/browse/NET-158
 Project: Commons Net
  Issue Type: Bug
Affects Versions: 1.4
Reporter: Gilles Gaillard
Priority: Trivial

 When a password is required to connect the FTP server, the implementation of 
 method login in class FTPClient ends with:
   return FTPReply.isPositiveCompletion(pass(password))
 which returns false for any code = 300.
 However, some servers send a code 451 before returning the code 530 
 (NOT_LOGGED_IN). Ignoring this addtional answer,
 leads to desynch the client with the server, hence leading to unexpected 
 behaviors in next exchanges.
 Threfore i propose to replace the above code in the end of the method with:
   _replyCode = p_Client.pass(p_Password);
   boolean result = FTPReply.isPositiveCompletion(_replyCode);
   if (!result  _replyCode==FTPReply.ACTION_ABORTED){
 try {
   _replyCode = p_Client.getReply();
 } catch (Exception e){
   e.printStackTrace();
 }
   }
   return result;

-- 
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: r530033 - in /jakarta/commons/proper/commons-build/trunk: menus/components-items.ent menus/sandbox-items.ent parts/components-table.ent parts/sandbox-table.ent

2007-04-18 Thread niallp
Author: niallp
Date: Wed Apr 18 07:29:56 2007
New Revision: 530033

URL: http://svn.apache.org/viewvc?view=revrev=530033
Log:
Update site to reflect JCI moving from Sandbox to Proper

Modified:
jakarta/commons/proper/commons-build/trunk/menus/components-items.ent
jakarta/commons/proper/commons-build/trunk/menus/sandbox-items.ent
jakarta/commons/proper/commons-build/trunk/parts/components-table.ent
jakarta/commons/proper/commons-build/trunk/parts/sandbox-table.ent

Modified: jakarta/commons/proper/commons-build/trunk/menus/components-items.ent
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/commons-build/trunk/menus/components-items.ent?view=diffrev=530033r1=530032r2=530033
==
--- jakarta/commons/proper/commons-build/trunk/menus/components-items.ent 
(original)
+++ jakarta/commons/proper/commons-build/trunk/menus/components-items.ent Wed 
Apr 18 07:29:56 2007
@@ -16,6 +16,7 @@
 item name=FileUpload
href=http://jakarta.apache.org/commons/fileupload//
 item name=HttpClient
href=http://jakarta.apache.org/commons/httpclient//
 item name=IO
href=http://jakarta.apache.org/commons/io//
+item name=JCI   
href=http://jakarta.apache.org/commons/jci//
 item name=Jelly 
href=http://jakarta.apache.org/commons/jelly//
 item name=Jexl  
href=http://jakarta.apache.org/commons/jexl//
 item name=JXPath
href=http://jakarta.apache.org/commons/jxpath//

Modified: jakarta/commons/proper/commons-build/trunk/menus/sandbox-items.ent
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/commons-build/trunk/menus/sandbox-items.ent?view=diffrev=530033r1=530032r2=530033
==
--- jakarta/commons/proper/commons-build/trunk/menus/sandbox-items.ent 
(original)
+++ jakarta/commons/proper/commons-build/trunk/menus/sandbox-items.ent Wed Apr 
18 07:29:56 2007
@@ -5,7 +5,6 @@
 item name=I18n  
href=http://jakarta.apache.org/commons/sandbox/i18n//
 item name=Id
href=http://jakarta.apache.org/commons/sandbox/id//
 item name=Javaflow  
href=http://jakarta.apache.org/commons/sandbox/javaflow//
-item name=JCI   
href=http://jakarta.apache.org/commons/sandbox/jci//
 item name=OpenPGP   
href=http://jakarta.apache.org/commons/sandbox/openpgp//
 item name=Pipeline  
href=http://jakarta.apache.org/commons/sandbox/pipeline//
 item name=Proxy 
href=http://jakarta.apache.org/commons/sandbox/proxy//

Modified: jakarta/commons/proper/commons-build/trunk/parts/components-table.ent
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/commons-build/trunk/parts/components-table.ent?view=diffrev=530033r1=530032r2=530033
==
--- jakarta/commons/proper/commons-build/trunk/parts/components-table.ent 
(original)
+++ jakarta/commons/proper/commons-build/trunk/parts/components-table.ent Wed 
Apr 18 07:29:56 2007
@@ -109,6 +109,12 @@
 /td
 /tr
 tr
+tda href=http://jakarta.apache.org/commons/jci/;JCI/a/td
+td
+ Java Compiler Interface
+/td
+/tr
+tr
 tda href=http://jakarta.apache.org/commons/jelly/;Jelly/a/td
 td
  XML based scripting and processing engine. 

Modified: jakarta/commons/proper/commons-build/trunk/parts/sandbox-table.ent
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/commons-build/trunk/parts/sandbox-table.ent?view=diffrev=530033r1=530032r2=530033
==
--- jakarta/commons/proper/commons-build/trunk/parts/sandbox-table.ent 
(original)
+++ jakarta/commons/proper/commons-build/trunk/parts/sandbox-table.ent Wed Apr 
18 07:29:56 2007
@@ -43,12 +43,6 @@
 /td
 /tr
 tr
-tda href=http://jakarta.apache.org/commons/sandbox/jci/;JCI/a/td
-td
- Java Compiler Interface
-/td
-/tr
-tr
 tda 
href=http://jakarta.apache.org/commons/sandbox/openpgp/;OpenPGP/a/td
 td
   Interface to signing and verifying data using OpenPGP.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Commented: (NET-158) login in FTPClient does not always read the complete server response

2007-04-18 Thread Rory Winston (JIRA)

[ 
https://issues.apache.org/jira/browse/NET-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489777
 ] 

Rory Winston commented on NET-158:
--

Thanks Gilles, I will have a look at this. Do you happen to know what the FTP 
server is (i.e,. what software - wuftpd)?

 login in FTPClient does not always read the complete server response
 

 Key: NET-158
 URL: https://issues.apache.org/jira/browse/NET-158
 Project: Commons Net
  Issue Type: Bug
Affects Versions: 1.4
Reporter: Gilles Gaillard
Priority: Trivial

 When a password is required to connect the FTP server, the implementation of 
 method login in class FTPClient ends with:
   return FTPReply.isPositiveCompletion(pass(password))
 which returns false for any code = 300.
 However, some servers send a code 451 before returning the code 530 
 (NOT_LOGGED_IN). Ignoring this addtional answer,
 leads to desynch the client with the server, hence leading to unexpected 
 behaviors in next exchanges.
 Threfore i propose to replace the above code in the end of the method with:
   _replyCode = p_Client.pass(p_Password);
   boolean result = FTPReply.isPositiveCompletion(_replyCode);
   if (!result  _replyCode==FTPReply.ACTION_ABORTED){
 try {
   _replyCode = p_Client.getReply();
 } catch (Exception e){
   e.printStackTrace();
 }
   }
   return result;

-- 
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: r530051 - in /jakarta/commons/proper/commons-build/trunk: project.xml xdocs/building.xml xdocs/components.xml xdocs/releases/prepare.xml xdocs/releases/release.xml

2007-04-18 Thread niallp
Author: niallp
Date: Wed Apr 18 08:12:24 2007
New Revision: 530051

URL: http://svn.apache.org/viewvc?view=revrev=530051
Log:
Fix broken links

Modified:
jakarta/commons/proper/commons-build/trunk/project.xml
jakarta/commons/proper/commons-build/trunk/xdocs/building.xml
jakarta/commons/proper/commons-build/trunk/xdocs/components.xml
jakarta/commons/proper/commons-build/trunk/xdocs/releases/prepare.xml
jakarta/commons/proper/commons-build/trunk/xdocs/releases/release.xml

Modified: jakarta/commons/proper/commons-build/trunk/project.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/commons-build/trunk/project.xml?view=diffrev=530051r1=530050r2=530051
==
--- jakarta/commons/proper/commons-build/trunk/project.xml (original)
+++ jakarta/commons/proper/commons-build/trunk/project.xml Wed Apr 18 08:12:24 
2007
@@ -60,13 +60,13 @@
   nameCommons Dev List/name
   subscribe[EMAIL PROTECTED]/subscribe
   unsubscribe[EMAIL PROTECTED]/unsubscribe
-  archivehttp://mail-archives.apache.org/eyebrowse/[EMAIL 
PROTECTED]/archive
+  
archivehttp://mail-archives.apache.org/mod_mbox/jakarta-commons-dev//archive
 /mailingList
 mailingList
   nameCommons User List/name
   subscribe[EMAIL PROTECTED]/subscribe
   unsubscribe[EMAIL PROTECTED]/unsubscribe
-  archivehttp://mail-archives.apache.org/eyebrowse/[EMAIL 
PROTECTED]/archive
+  
archivehttp://mail-archives.apache.org/mod_mbox/jakarta-commons-user//archive
 /mailingList
   /mailingLists
   

Modified: jakarta/commons/proper/commons-build/trunk/xdocs/building.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/commons-build/trunk/xdocs/building.xml?view=diffrev=530051r1=530050r2=530051
==
--- jakarta/commons/proper/commons-build/trunk/xdocs/building.xml (original)
+++ jakarta/commons/proper/commons-build/trunk/xdocs/building.xml Wed Apr 18 
08:12:24 2007
@@ -42,7 +42,7 @@
 /p
 p
 Some knowledge of maven is assumed in this document.  Please refer to the
-a href=http://maven.apache.org/using/index.html;maven user guide/a and
+a href=http://maven.apache.org/maven-1.x/using/index.html;maven user 
guide/a and
 a 
href=http://maven.apache.org/maven-1.x/reference/index.html;reference/a
 for more information. Most commons components now use version 1 of maven,
 so this is the maven version assumed throughout this document. Updates
@@ -60,7 +60,7 @@
 subsection name='Getting and installing maven'
   p
   Follow the 
-  a href=http://maven.apache.org/start/download.html;
+  a href=http://maven.apache.org/maven-1.x/start/download.html;
   maven download instructions/a to download and install maven. You will
   need Maven version 1.0.2.
   /p
@@ -127,7 +127,7 @@
   section name='Maven POM (project.xml) configuration'
   p
   This section describes the key elements in the maven POM and how the 
-  a 
href=http://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build/trunk/project.xml.sample;
+  a 
href=http://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build/trunk/samples/project.xml.sample;
   sample codeproject.xml/code/a file needs to be modified or customized
   for different components.
   /p 
@@ -194,7 +194,7 @@
   codemaven-changes-plugin/code should only be used if the component
   maintains a codechanges.xml/code file in code/xdocs/code 
   following the format described in the
-  a href=http://maven.apache.org/maven-1.x/reference/plugins/changes/;
+  a href=http://maven.apache.org/maven-1.x/plugins/changes/;
   maven changes plugin documentation/a/td/tr/table
   /p
 /subsection
@@ -204,7 +204,7 @@
 p
 There is very little that needs to be customized for individual components
 in the
-a 
href=http://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build/trunk/project.properties.sample;
+a 
href=http://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build/trunk/samples/project.properties.sample;
 sample codeproject.properties/code file/a. The table below calls out
 a few properties which individual components may wish to modify.  The
 deployment and site generation properties (which should not be changed) are
@@ -230,7 +230,7 @@
 Use codemaven site:generate/code to generate the component web site
 locally. Then review the generated html in codetarget/docs./code
 Navigation is specified in codexdocs/navigation.xml./code The
-a 
href=http://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build/trunk/navigation.xml.sample;
+a 
href=http://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build/trunk/samples/navigation.xml.sample;
 sample navigation file/a refers to entities defined in 
 code../../commons-build/menus/menus.dtd,/code so, as 

[jira] Commented: (NET-158) login in FTPClient does not always read the complete server response

2007-04-18 Thread Gilles Gaillard (JIRA)

[ 
https://issues.apache.org/jira/browse/NET-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489784
 ] 

Gilles Gaillard commented on NET-158:
-

No sorry, i investagted but this one is from my IAP.

 login in FTPClient does not always read the complete server response
 

 Key: NET-158
 URL: https://issues.apache.org/jira/browse/NET-158
 Project: Commons Net
  Issue Type: Bug
Affects Versions: 1.4
Reporter: Gilles Gaillard
Priority: Trivial

 When a password is required to connect the FTP server, the implementation of 
 method login in class FTPClient ends with:
   return FTPReply.isPositiveCompletion(pass(password))
 which returns false for any code = 300.
 However, some servers send a code 451 before returning the code 530 
 (NOT_LOGGED_IN). Ignoring this addtional answer,
 leads to desynch the client with the server, hence leading to unexpected 
 behaviors in next exchanges.
 Threfore i propose to replace the above code in the end of the method with:
   _replyCode = p_Client.pass(p_Password);
   boolean result = FTPReply.isPositiveCompletion(_replyCode);
   if (!result  _replyCode==FTPReply.ACTION_ABORTED){
 try {
   _replyCode = p_Client.getReply();
 } catch (Exception e){
   e.printStackTrace();
 }
   }
   return result;

-- 
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] Created: (VFS-127) Need ability to set default timeout on FTP provider

2007-04-18 Thread Tom Duffey (JIRA)
Need ability to set default timeout on FTP provider
---

 Key: VFS-127
 URL: https://issues.apache.org/jira/browse/VFS-127
 Project: Commons VFS
  Issue Type: Improvement
Affects Versions: 1.0
Reporter: Tom Duffey


VFS currently allows setting the data timeout for FTP connections but does 
not provide any way to set the default timeout for establishing new 
connections.  This would be extremely useful because otherwise the connection 
will hang forever.  The fix is trivial, I'll supply a patch later but in 
general you just add another option to the FtpFileSystemConfigBuilder and then 
when set you call:

client.setDefaultTimeout(value)

in FtpClientFactory.java


-- 
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: (VFS-127) Need ability to set default timeout on FTP provider

2007-04-18 Thread Tom Duffey (JIRA)

[ 
https://issues.apache.org/jira/browse/VFS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489830
 ] 

Tom Duffey commented on VFS-127:


Actually, this won't be very useful into Commons Net 2.0 thanks to 1.4.x not 
really supporting connection timeouts.

 Need ability to set default timeout on FTP provider
 ---

 Key: VFS-127
 URL: https://issues.apache.org/jira/browse/VFS-127
 Project: Commons VFS
  Issue Type: Improvement
Affects Versions: 1.0
Reporter: Tom Duffey

 VFS currently allows setting the data timeout for FTP connections but does 
 not provide any way to set the default timeout for establishing new 
 connections.  This would be extremely useful because otherwise the connection 
 will hang forever.  The fix is trivial, I'll supply a patch later but in 
 general you just add another option to the FtpFileSystemConfigBuilder and 
 then when set you call:
 client.setDefaultTimeout(value)
 in FtpClientFactory.java

-- 
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: (DBCP-146) [dbcp] Invalidate broken connections by monitoring SQLExceptions

2007-04-18 Thread Markus Krogemann (JIRA)

[ 
https://issues.apache.org/jira/browse/DBCP-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489850
 ] 

Markus Krogemann commented on DBCP-146:
---

Phil, you are right. I got around the issue with a combination of 
testOnBorrow/testWhileIdle. 

Still, it would be an interesting addition to the already great capabilities of 
dbcp for the 'configuration-lazy' people among us ;-)

Having said that, it might even prove to be counter-productive to add features 
like that if users are not aware of them, so maybe it should not be implemented 
at all...

I am not in a position to decide that. However, if you are looking for testers 
of such a feature, i am prepared to help out.

Thanks for now,
Markus

 [dbcp] Invalidate broken connections by monitoring SQLExceptions
 --

 Key: DBCP-146
 URL: https://issues.apache.org/jira/browse/DBCP-146
 Project: Commons Dbcp
  Issue Type: Improvement
Affects Versions: 1.1
 Environment: Operating System: All
 Platform: All
Reporter: Dirk Verbeeck
Priority: Minor
 Fix For: 1.3

 Attachments: brokenConn-patch.txt


 A PoolableConnection can know when it is broken. (When a fatal SQLException 
 is
 thrown.) A SQLException is considered fatal when it includes an error code 
 from
 a configurable list of broken connection indicators.
 The attached patch is a partial implementation for review 
 (not all Delegating* methods are covered)
 Summary:
 Add a list of indicators that (when found in an SQLException) mark a 
 Connection
 as broken. Broken Connections will be destroyed and not returned to the 
 pool.
 if (!isBroken()) {
 _pool.returnObject(this);
 } else {
 _pool.invalidateObject(this);
 }

-- 
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: r530143 - /jakarta/commons/proper/configuration/trunk/project.xml

2007-04-18 Thread oheger
Author: oheger
Date: Wed Apr 18 12:54:27 2007
New Revision: 530143

URL: http://svn.apache.org/viewvc?view=revrev=530143
Log:
Added explicit dependency to checkstyle plugin to ensure that the correct 
version is used

Modified:
jakarta/commons/proper/configuration/trunk/project.xml

Modified: jakarta/commons/proper/configuration/trunk/project.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/project.xml?view=diffrev=530143r1=530142r2=530143
==
--- jakarta/commons/proper/configuration/trunk/project.xml (original)
+++ jakarta/commons/proper/configuration/trunk/project.xml Wed Apr 18 12:54:27 
2007
@@ -434,6 +434,14 @@
 /dependency
 
 dependency
+  groupIdmaven/groupId
+  artifactIdmaven-checkstyle-plugin/artifactId
+  version3.0.1/version
+  urlhttp://maven.apache.org/maven-1.x/plugins/checkstyle//url
+  typeplugin/type
+/dependency
+
+dependency
   groupIdmaven-plugins/groupId
   artifactIdmaven-cobertura-plugin/artifactId
   version1.2/version



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [configuration] Re: [nightly build] configuration failed.

2007-04-18 Thread Oliver Heger

Emmanuel Bourg wrote:
I did a fresh install of Maven 1.0.2 on people.apache.org (FreeBSD 6.1, 
Java 5u7), with a fresh checkout of the code, and ran 'maven site'. The 
build failed on checkstyle with this error :


Unable to create a Checker: cannot initialize module TreeWalker - 
Property 'allowMissingJavadoc' in module JavadocMethod does not exist, 
please check the documentation


I had the same issue on my laptop, this property exists in the 
checkstyle documentation though. I removed the offending line and 
restarted the site generation, it completed normally.


Now I wonder why Phil's nightly builds report an xdoc error and not the 
checkstyle error. What command is used to start the nightly build ?


Emmanuel Bourg

I added an explicit dependency to the newest version of the checkstyle 
plugin to project.xml. This should solve the problem with checkstyle. 
For the other problem I agree with Nial's answer: Obviously the lower 
version of the xdoc plugin causes more problems than it solves. So we 
should better go with the current version, especially if this is the 
standard for most of the commons components.


Now the new dependency to javax.mail causes me trouble: Compiling with 
JDK 1.3 fails now because the compiler reports an invalid class version. 
The mail jar has been compiled with a JDK  1.3. So what do we do?


In general I wonder whether all these specialized get methods make sense 
for DataConfiguration. Wouldn't it be better and more flexible to have a 
generic method


Object getProperty(String key, Class targetClass)

and then provide a means for registering arbitrary converters? We could 
indeed use the Beanutils converters for this purpose as was suggested by 
one jira ticket.


Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[Jakarta-commons Wiki] Update of Brainstorm Transaction 2.0 by OliverZeigermann

2007-04-18 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki 
for change notification.

The following page has been changed by OliverZeigermann:
http://wiki.apache.org/jakarta-commons/Brainstorm_Transaction_2%2e0

--
* keep it slim and rudimentary
* amounts to a transactional file store out of the box
  
+ Features of transaction implementation:
+  * a transaction is defined by a set of locks, a timeout and some sort of 
resource manager
+  * supply a watchdog thread that takes care of deadlocks and timed out 
transaction
+  * when a transaction is rolled back
+   * the resource manager is told to roll back all changes 
+   * all locks of the lock set are freed
+ 
- Features of the file implementation:
+ Features of the file resource manager implementation:
   * allow for additional guaranteed deadlock free actions on resources
* move and tree-move
* copy and tree-copy
* delete and tree-delete
   * maintain an explicit tree (graph?) structure
   * provide an administration interface based on JMX
+  * change the transaction scheme to perform actions as they are requested and 
maintain a roll back log. In case of commit nothing will be done, in case of a 
rollback all changes will be reverted according to the roll back log. 
Eventually, all locks will be released.
  
  Testing:
   * Testing should be based on JUnit 4

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed

2007-04-18 Thread commons-jelly-tags-jsl development
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-jsl-test has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 151 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-jsl-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on ant exists, no need to add for property 
maven.jar.ant-optional.
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html
Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 16 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-18042007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-18042007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-18042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-18042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-18042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-18042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-18042007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-18042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-18042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-18042007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-18042007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar
-
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:64)
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:59)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96)
[junit] at 
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187)
[junit] at 
org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:66)
[junit] at 
org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:113)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96)
[junit] at 
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187)
[junit] at 
org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:161)
[junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59)
[junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80)
[junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171)
[junit] 

[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed

2007-04-18 Thread commons-jelly-tags-jsl development
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-jsl-test has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 151 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-jsl-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on ant exists, no need to add for property 
maven.jar.ant-optional.
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html
Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 16 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-18042007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-18042007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-18042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-18042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-18042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-18042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-18042007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-18042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-18042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-18042007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-18042007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar
-
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:64)
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:59)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96)
[junit] at 
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187)
[junit] at 
org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:66)
[junit] at 
org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:113)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96)
[junit] at 
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187)
[junit] at 
org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:161)
[junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59)
[junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80)
[junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171)
[junit] 

[CSV] How to start?

2007-04-18 Thread sp

Good evening,

in two projects of mine I use something like a CSV-Object Mapper, which I
have developed. I would like to share it and make a project of it. My
mapper goes a lot further than the three existing csv-projects, but is not
much code either.

by Sebastian

[EMAIL PROTECTED]: Project commons-jelly-tags-fmt-test (in module commons-jelly) failed

2007-04-18 Thread commons-jelly-tags-fmt development
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-fmt-test has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 151 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-fmt-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/gump_work/build_commons-jelly_commons-jelly-tags-fmt-test.html
Work Name: build_commons-jelly_commons-jelly-tags-fmt-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 11 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-util-2.0b4.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-18042007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-18042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-18042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-18042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-18042007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-18042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-18042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-18042007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-18042007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/commons-jelly-tags-fmt-18042007.jar
-
[junit] at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
[junit] at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
[junit] at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
[junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
[junit] at java.security.AccessController.doPrivileged(Native Method)
[junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
[junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
[junit] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
[junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
[junit] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
[junit] at 
org.apache.commons.jelly.tags.ant.AntTagLibrary.createProject(AntTagLibrary.java:128)

[EMAIL PROTECTED]: Project commons-jelly-tags-fmt-test (in module commons-jelly) failed

2007-04-18 Thread commons-jelly-tags-fmt development
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-fmt-test has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 151 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-fmt-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/gump_work/build_commons-jelly_commons-jelly-tags-fmt-test.html
Work Name: build_commons-jelly_commons-jelly-tags-fmt-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 11 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-util-2.0b4.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-18042007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-18042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-18042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-18042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-18042007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-18042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-18042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-18042007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-18042007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/commons-jelly-tags-fmt-18042007.jar
-
[junit] at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
[junit] at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
[junit] at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
[junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
[junit] at java.security.AccessController.doPrivileged(Native Method)
[junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
[junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
[junit] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
[junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
[junit] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
[junit] at 
org.apache.commons.jelly.tags.ant.AntTagLibrary.createProject(AntTagLibrary.java:128)

Re: [configuration] Re: [nightly build] configuration failed.

2007-04-18 Thread Emmanuel Bourg

Oliver Heger a écrit :

I added an explicit dependency to the newest version of the checkstyle 
plugin to project.xml. This should solve the problem with checkstyle.


Thank you Oliver and Niall, it does indeed fix this issue.


For the other problem I agree with Nial's answer: Obviously the lower 
version of the xdoc plugin causes more problems than it solves. So we 
should better go with the current version, especially if this is the 
standard for most of the commons components.


That's the easy solution I agree, I don't want to waste too much time 
getting the titles right if Maven impose its own standard.


But I'm concerned about our nightly reports sending false positives 
(xdoc) and missing real issues (checkstyle). Maybe it's time to 
reinstall Maven for the nightly builds, or is this too much trouble ?



Now the new dependency to javax.mail causes me trouble: Compiling with 
JDK 1.3 fails now because the compiler reports an invalid class version. 
The mail jar has been compiled with a JDK  1.3. So what do we do?


I'll check if we can use a previous version of javamail compatible with 
Java 1.3.



In general I wonder whether all these specialized get methods make sense 
for DataConfiguration. Wouldn't it be better and more flexible to have a 
generic method


Object getProperty(String key, Class targetClass)

and then provide a means for registering arbitrary converters? We could 
indeed use the Beanutils converters for this purpose as was suggested by 
one jira ticket.


Actually we have the generic methods ! :) I didn't add more specialized 
get methods in DataConfiguration for the new types, instead I introduced 
generic getters :


get(Class cls, String key)

getArray(Class cls, String key)

getList(Class cls, String key)


The specialized getters now call the generic getters (except for Date 
and Calendar), this cuts the nloc by a half. It might be worth moving 
these methods into AbstractConfiguration now, they offer the features of 
DataConfiguration without the horde of methods. They would be a nice 
addition to the Configuration interface for the next major release too.


Regarding the converters I believe we'll probably delegate this part to 
another API sooner or later (Morph, Beanutils...), but I don't want to 
add another core dependency. I was thinking about a pluggable conversion 
system, we would provide a basic implementation derived from the current 
code in PropertyConverter, and if someone wants more complex conversions 
he could plug a custom converter using another API.


Emmanuel Bourg







-
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

2007-04-18 Thread Nico Max (JIRA)

[ 
https://issues.apache.org/jira/browse/JXPATH-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489886
 ] 

Nico Max commented on JXPATH-80:


I've tracked this down and I think I was able to resolve the issue.

First off, my testbean was not public as for one reason for the test to fail 
... :-)

There is a method retrieving the length of a collection-like result of a bean 
getter in BeanPropertyPointer, but a real check for the NULL-case was missing, 
so I've patched that.

Unfortunately this does not fix your findings so I guess this issue should stay 
open.

 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]



[jira] Updated: (JXPATH-80) boolean conversion of javabean getter values returning NULL fails

2007-04-18 Thread Nico Max (JIRA)

 [ 
https://issues.apache.org/jira/browse/JXPATH-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nico Max updated JXPATH-80:
---

Attachment: patch.patch

 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: patch.patch, 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]



[jira] Updated: (JXPATH-80) boolean conversion of javabean getter values returning NULL fails

2007-04-18 Thread Nico Max (JIRA)

 [ 
https://issues.apache.org/jira/browse/JXPATH-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nico Max updated JXPATH-80:
---

Attachment: patch.patch

I've forgot to grant license; sorry

 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: patch.patch, patch.patch, 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]



[jira] Commented: (JXPATH-80) boolean conversion of javabean getter values returning NULL fails

2007-04-18 Thread Matt Benson (JIRA)

[ 
https://issues.apache.org/jira/browse/JXPATH-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489895
 ] 

Matt Benson commented on JXPATH-80:
---

Hmm, I had missed the isCollection() method.  The meat of your change--i.e. the 
part needed to make the testcase pass--is at the end of getLength():

-return ValueUtils.getLength(getBaseValue());
+return isCollection() ? ValueUtils.getLength(getBaseValue()) : 1;

Because isCollection() already returns false when the base value is null, I 
would feel okay about this change.  However, it breaks another testcase that 
tests whether the expression [1] returns a value relative to null.  The 
proposed change makes null have a size of 1, when the existing test expects no 
result due to null having a size of 0.  This still requires research into XPATH 
dogma.

 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: patch.patch, patch.patch, 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]



Re: [configuration] Re: [nightly build] configuration failed.

2007-04-18 Thread Emmanuel Bourg
Now the new dependency to javax.mail causes me trouble: Compiling with 
JDK 1.3 fails now because the compiler reports an invalid class 
version. The mail jar has been compiled with a JDK  1.3. So what do 
we do?


I'll check if we can use a previous version of javamail compatible with 
Java 1.3.


I haven't found a version easily usable by Maven that is compatible with 
Java 1.3. The Geronimo jars were compiled with Java 1.4.


We can either use javamail 1.3.3 from Sun (i.e more complex build 
instructions) or change the test case to use reflection (it will fail, 
but at least it compiles).


Emmanuel Bourg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



svn commit: r530205 - /jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestDataConfiguration.java

2007-04-18 Thread ebourg
Author: ebourg
Date: Wed Apr 18 16:46:34 2007
New Revision: 530205

URL: http://svn.apache.org/viewvc?view=revrev=530205
Log:
Changed TestDataConfiguration to make it compile and run on Java 1.3
Conversion to InternetAddress is no longer tested on Java 1.3

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=530205r1=530204r2=530205
==
--- 
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
 Wed Apr 18 16:46:34 2007
@@ -31,7 +31,8 @@
 import java.util.List;
 import java.util.Locale;
 import java.util.NoSuchElementException;
-import javax.mail.internet.InternetAddress;
+
+import org.apache.commons.lang.SystemUtils;
 
 import junit.framework.TestCase;
 import junitx.framework.ArrayAssert;
@@ -297,10 +298,10 @@
 conf.addProperty(ip.string.interpolated, ${ip.string});
 conf.addProperty(ip.object, InetAddress.getByName(127.0.0.1));
 
-// email address
+// email address (tested on Java 1.4+)
 conf.addProperty(email.string, [EMAIL PROTECTED]);
 conf.addProperty(email.string.interpolated, ${email.string});
-conf.addProperty(email.object, new InternetAddress([EMAIL 
PROTECTED]));
+conf.addProperty(email.object, [EMAIL PROTECTED]);
 }
 
 public void testGetConfiguration()
@@ -1692,21 +1693,27 @@
 
 public void testGetInternetAddress() throws Exception
 {
-InternetAddress expected = new InternetAddress([EMAIL PROTECTED]);
+if (!SystemUtils.isJavaVersionAtLeast(1.4f))
+{
+// skip the test on Java 1.3
+return;
+}
+
+Object expected = createInternetAddress([EMAIL PROTECTED]);
 
 // address as string
-assertEquals(expected, conf.get(InternetAddress.class, 
email.string));
+assertEquals(expected, conf.get(expected.getClass(), email.string));
 
 // address object
-assertEquals(expected, conf.get(InternetAddress.class, 
email.object));
+assertEquals(expected, conf.get(expected.getClass(), email.object));
 
 // interpolated value
-assertEquals(expected, conf.get(InternetAddress.class, 
email.string.interpolated));
+assertEquals(expected, conf.get(expected.getClass(), 
email.string.interpolated));
 
 conf.setProperty(email.invalid, [EMAIL PROTECTED]@org);
 try
 {
-conf.get(InternetAddress.class, email.invalid);
+conf.get(expected.getClass(), email.invalid);
 fail(ConversionException should be thrown for invalid emails);
 }
 catch (ConversionException e)
@@ -1715,7 +1722,18 @@
 }
 }
 
-public void testConversionException()
+/**
+ * Create an instance of InternetAddress. This trick is necessary to
+ * compile and run the test with Java 1.3 and the javamail-1.4 which
+ * is not compatible with Java 1.3
+ */
+private Object createInternetAddress(String email) throws Exception
+{
+Class cls = Class.forName(javax.mail.internet.InternetAddress);
+return cls.getConstructor(new Class[]{String.class}).newInstance(new 
Object[]{email});
+}
+
+public void testConversionException() throws Exception
 {
 conf.addProperty(key1, new Object());
 conf.addProperty(key2, xx);
@@ -2330,14 +2348,18 @@
 // expected
 }
 
-try
-{
-conf.get(InternetAddress.class, key1);
-fail(getInternetAddress didn't throw a ConversionException);
-}
-catch (ConversionException e)
+if (SystemUtils.isJavaVersionAtLeast(1.4f))
 {
-// expected
+// skip the test on Java 1.3
+try
+{
+conf.get(Class.forName(javax.mail.internet.InternetAddress), 
key1);
+fail(getInternetAddress didn't throw a ConversionException);
+}
+catch (ConversionException e)
+{
+// expected
+}
 }
 }
 }



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [configuration] Re: [nightly build] configuration failed.

2007-04-18 Thread Emmanuel Bourg
I changed TestDataConfiguration using reflection, let me know how it 
works for you. The tests with InternetAddress are skipped on Java 1.3.


Emmanuel Bourg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



svn commit: r530207 - /jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestDataConfiguration.java

2007-04-18 Thread ebourg
Author: ebourg
Date: Wed Apr 18 16:53:50 2007
New Revision: 530207

URL: http://svn.apache.org/viewvc?view=revrev=530207
Log:
Follow up on TestDataConfiguration fix

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=530207r1=530206r2=530207
==
--- 
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
 Wed Apr 18 16:53:50 2007
@@ -299,9 +299,12 @@
 conf.addProperty(ip.object, InetAddress.getByName(127.0.0.1));
 
 // email address (tested on Java 1.4+)
-conf.addProperty(email.string, [EMAIL PROTECTED]);
-conf.addProperty(email.string.interpolated, ${email.string});
-conf.addProperty(email.object, [EMAIL PROTECTED]);
+if (SystemUtils.isJavaVersionAtLeast(1.4f))
+{
+conf.addProperty(email.string, [EMAIL PROTECTED]);
+conf.addProperty(email.string.interpolated, ${email.string});
+conf.addProperty(email.object, createInternetAddress([EMAIL 
PROTECTED]));
+}
 }
 
 public void testGetConfiguration()



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]