RE: Moving from Bugzilla to JIRA
-0 from me to move to JIRA, +0 to stay on Bugzilla. I think the OSS support argument is significant. Yoav Shapira Millennium Research Informatics -Original Message- From: Tim O'Brien [mailto:[EMAIL PROTECTED] Sent: Friday, September 03, 2004 8:44 AM To: Jakarta Commons Developers List Subject: RE: Moving from Bugzilla to JIRA You know my views on JIRA, just search the archives of commons-dev. +1 move to JIRA Tim -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Friday, September 03, 2004 7:25 AM To: Jakarta Commons Developers List Subject: RE: Moving from Bugzilla to JIRA I'd like to be using JIRA rather than Bugzilla. Release planning feels possible in JIRA, whereas in Bugzilla it always feels like something so painful it is not worth the effort you'd have to put in. In fact, I'm currently using the Wiki to try to simulate the release process in JIRA :) +1 Hen On Fri, 3 Sep 2004, [iso-8859-1] Eduardo Sebastián Marco wrote: I think it should be necessary to have a vote, but I don't think like Gary does. I think the matter here is not whether we support opensource or not... Of course we do! I think the matter here is excelence. And in my opinion, if there's something actually better and it's avalaible, why not? Is that or getting involved on the lesser tool to make it better. Eduardo. -Mensaje original- De: Gary Gregory [mailto:[EMAIL PROTECTED] Enviado el: viernes, 03 de septiembre de 2004 1:59 Para: Jakarta Commons Developers List; Dion Gillard Asunto: RE: Moving from Bugzilla to JIRA On principle, I am not in favor of moving /away/ from Bugzilla, an open-source project, to Jira, a non-open-source project. It feels to me that this would send a negative message, as in: we are not supporting the open-source community. OTOH, this is software evolution at work. I have heard good things about JIRA, but not used it much beyond filing a couple of tickets vs. Maven. Gary -Original Message- From: Dion Gillard [mailto:[EMAIL PROTECTED] Sent: Thursday, September 02, 2004 15:40 To: Jakarta Commons Developers List Subject: Moving from Bugzilla to JIRA I've found out that the JIRA import process from Bugzilla can only import a whole project, and not components, and hence all of jakarta-commons has to go together. Does anyone still want to stay on Bugzilla? Do we need a vote for this? -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving from Bugzilla to JIRA
I prefer to stick with Bugzilla, for ethical and technical reasons. Bugzilla is good enough for my needs, I prefer to promote an open source product, and an upgrade of the version currently deployed on Nagoya is planned sooner or later. -1 on migrating [configuration] to JIRA. Emmanuel Bourg Dion Gillard wrote: I've found out that the JIRA import process from Bugzilla can only import a whole project, and not components, and hence all of jakarta-commons has to go together. Does anyone still want to stay on Bugzilla? Do we need a vote for this? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/dbutils/src/java/org/apache/commons/dbutils DbUtils.java
dgraham 2004/09/03 06:01:58
Modified:dbutils/src/java/org/apache/commons/dbutils DbUtils.java
Log:
Minor cleanup.
Revision ChangesPath
1.5 +17 -26
jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/DbUtils.java
Index: DbUtils.java
===
RCS file:
/home/cvs/jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/DbUtils.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- DbUtils.java 28 Feb 2004 00:12:23 - 1.4
+++ DbUtils.java 3 Sep 2004 13:01:58 - 1.5
@@ -70,24 +70,22 @@
* codeResultSet/code. Avoid closing if null and hide any
* SQLExceptions that occur.
*/
-public static void closeQuietly(
-Connection conn,
-Statement stmt,
-ResultSet rs) {
-
+public static void closeQuietly(Connection conn, Statement stmt,
+ResultSet rs) {
+
closeQuietly(rs);
closeQuietly(stmt);
closeQuietly(conn);
}
/**
- * Close a codeResultSet/code, avoid closing if null and hide
- * any SQLExceptions that occur.
+ * Close a codeResultSet/code, avoid closing if null and hide any
+ * SQLExceptions that occur.
*/
public static void closeQuietly(ResultSet rs) {
try {
close(rs);
-} catch (SQLException sqle) {
+} catch (SQLException e) {
// quiet
}
}
@@ -99,7 +97,7 @@
public static void closeQuietly(Statement stmt) {
try {
close(stmt);
-} catch (SQLException sqle) {
+} catch (SQLException e) {
// quiet
}
}
@@ -121,7 +119,7 @@
public static void commitAndCloseQuietly(Connection conn) {
try {
commitAndClose(conn);
-} catch (SQLException sqle) {
+} catch (SQLException e) {
// quiet
}
}
@@ -136,34 +134,27 @@
return true;
} catch (ClassNotFoundException e) {
-// TODO Logging?
-//e.printStackTrace();
return false;
} catch (IllegalAccessException e) {
-// TODO Logging?
-//e.printStackTrace();
-
// Constructor is private, OK for DriverManager contract
return true;
} catch (InstantiationException e) {
-// TODO Logging?
-//e.printStackTrace();
return false;
-} catch (Throwable t) {
+} catch (Throwable e) {
return false;
}
}
-public static void printStackTrace(SQLException sqle) {
-printStackTrace(sqle, new PrintWriter(System.err));
+public static void printStackTrace(SQLException e) {
+printStackTrace(e, new PrintWriter(System.err));
}
-public static void printStackTrace(SQLException sqle, PrintWriter pw) {
+public static void printStackTrace(SQLException e, PrintWriter pw) {
-SQLException next = sqle;
+SQLException next = e;
while (next != null) {
next.printStackTrace(pw);
next = next.getNextException();
@@ -173,16 +164,16 @@
}
}
-public static void printWarnings(Connection connection) {
-printWarnings(connection, new PrintWriter(System.err));
+public static void printWarnings(Connection conn) {
+printWarnings(conn, new PrintWriter(System.err));
}
public static void printWarnings(Connection conn, PrintWriter pw) {
if (conn != null) {
try {
printStackTrace(conn.getWarnings(), pw);
-} catch (SQLException sqle) {
-printStackTrace(sqle, pw);
+} catch (SQLException e) {
+printStackTrace(e, pw);
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/dbutils/src/java/org/apache/commons/dbutils DbUtils.java
dgraham 2004/09/03 06:04:32
Modified:dbutils/src/java/org/apache/commons/dbutils DbUtils.java
Log:
Added a try/finally block in commitAndClose() to ensure the connection is always
closed.
Revision ChangesPath
1.6 +6 -3
jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/DbUtils.java
Index: DbUtils.java
===
RCS file:
/home/cvs/jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/DbUtils.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- DbUtils.java 3 Sep 2004 13:01:58 - 1.5
+++ DbUtils.java 3 Sep 2004 13:04:32 - 1.6
@@ -60,7 +60,7 @@
public static void closeQuietly(Connection conn) {
try {
close(conn);
-} catch (SQLException sqle) {
+} catch (SQLException e) {
// quiet
}
}
@@ -107,8 +107,11 @@
*/
public static void commitAndClose(Connection conn) throws SQLException {
if (conn != null) {
-conn.commit();
-conn.close();
+try {
+conn.commit();
+} finally {
+conn.close();
+}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/dbutils/src/java/org/apache/commons/dbutils DbUtils.java
dgraham 2004/09/03 06:07:30
Modified:dbutils/src/java/org/apache/commons/dbutils DbUtils.java
Log:
Added a try/finally block in closeQuietly() to ensure the connection is always
closed.
Revision ChangesPath
1.7 +10 -3
jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/DbUtils.java
Index: DbUtils.java
===
RCS file:
/home/cvs/jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/DbUtils.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- DbUtils.java 3 Sep 2004 13:04:32 - 1.6
+++ DbUtils.java 3 Sep 2004 13:07:30 - 1.7
@@ -73,9 +73,16 @@
public static void closeQuietly(Connection conn, Statement stmt,
ResultSet rs) {
-closeQuietly(rs);
-closeQuietly(stmt);
-closeQuietly(conn);
+try {
+closeQuietly(rs);
+} finally {
+try {
+closeQuietly(stmt);
+} finally {
+closeQuietly(conn);
+}
+}
+
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Moving from Bugzilla to JIRA
I'd like to point out that over in Struts, this parallel discussion came to a rest on the acknowledgement that Struts has such strong ties to Commons that it doesn't make sense for Struts to change to JIRA if Commons remains on Bugzilla. Bugs filed against Struts often resolve to commons components and need to be shuttled over. There may be other projects like Struts that have this situation. Also in those discussions it was pointed out that perceived issues with Apache's Bugzilla may be more to do with the installation we have than with the application itself, and that improvements could be made there. I don't know much about it, but perhaps this would be something of interest to those who don't want to move to JIRA because it's not open source. I think JIRA is great software, Atlassian are good open-source citizens, and I have no personal interest in learning how to make Bugzilla work better, so my votes are all going to go in the direction of moving to JIRA. I do agree that Struts should use whatever Commons uses, or if Commons projects move partially (as Jelly has demonstrated is possible), then Struts should wait to move until its dependencies move. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/dbutils/xdocs changes.xml
dgraham 2004/09/03 06:14:07
Modified:dbutils/src/java/org/apache/commons/dbutils DbUtils.java
dbutils/xdocs changes.xml
Log:
Added rollbackAndClose() and rollbackAndCloseQuietly() to DbUtils.
Revision ChangesPath
1.8 +28 -0
jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/DbUtils.java
Index: DbUtils.java
===
RCS file:
/home/cvs/jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/DbUtils.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- DbUtils.java 3 Sep 2004 13:07:30 - 1.7
+++ DbUtils.java 3 Sep 2004 13:14:07 - 1.8
@@ -198,5 +198,33 @@
conn.rollback();
}
}
+
+/**
+ * Performs a rollback on the codeConnection/code then closes it,
+ * avoid closing if null.
+ * @since DbUtils 1.1
+ */
+public static void rollbackAndClose(Connection conn) throws SQLException {
+if (conn != null) {
+try {
+conn.rollback();
+} finally {
+conn.close();
+}
+}
+}
+
+/**
+ * Performs a rollback on the codeConnection/code then closes it,
+ * avoid closing if null and hide any SQLExceptions that occur.
+ * @since DbUtils 1.1
+ */
+public static void rollbackAndCloseQuietly(Connection conn) {
+try {
+rollbackAndClose(conn);
+} catch (SQLException e) {
+// quiet
+}
+}
}
1.5 +3 -0 jakarta-commons/dbutils/xdocs/changes.xml
Index: changes.xml
===
RCS file: /home/cvs/jakarta-commons/dbutils/xdocs/changes.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- changes.xml 23 Aug 2004 02:10:32 - 1.4
+++ changes.xml 3 Sep 2004 13:14:07 - 1.5
@@ -39,6 +39,9 @@
body
release version=1.1-dev date=in CVS
+ action dev=dgraham type=add
+Added DbUtils.rollbackAndClose() and DbUtils.rollbackAndCloseQuietly().
+ /action
action dev=dgraham type=update
Call ResultSet.getTimestamp() in BeanProcessor.processColumn() if
the bean property is a java.sql.Timestamp. Oracle's getObject()
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBUtils] additional DBUtils class helper methods request
Done. This will be in the next nightly build. David --- Kyle Miller [EMAIL PROTECTED] wrote: Could you please add the following two methods to the DBUtils helper class: rollbackAndClose(...); rollbackAndCloseQuietly(...); to mimic the commit and close methods. Thanks, Kyle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving from Bugzilla to JIRA
I'd also be +1 but I am a bit bothered by the political impact of depending on a commercial product as strong open-source veteran. Currently +0. If Bugzilla skins would exist (they are possible) and be used and usable, I think such discussion would be way more futile. Unfortunately, I haven't seen any. As of Scarab, I still haven't managed to get a demo-account to be opened for me on any demo-server... which is not a really good sign, I feel. paul PS: the bugzilla/jira opposition is a real feel for open-source can't do GUIs wich is really something a bit too widespread. PPS: I haven't done it but you can export all Bugzilla bugs of one product and only keep the ones for a given component, leaving quiet the bugzilla ones... so the need for a complete migration isn't really there except it takes more time to migrate a single component. Le 3 sept. 04, à 14:24, Henri Yandell a écrit : I'd like to be using JIRA rather than Bugzilla. Release planning feels possible in JIRA, whereas in Bugzilla it always feels like something so painful it is not worth the effort you'd have to put in. In fact, I'm currently using the Wiki to try to simulate the release process in JIRA :) +1 Hen On Fri, 3 Sep 2004, [iso-8859-1] Eduardo Sebastián Marco wrote: I think it should be necessary to have a vote, but I don't think like Gary does. I think the matter here is not whether we support opensource or not... Of course we do! I think the matter here is excelence. And in my opinion, if there's something actually better and it's avalaible, why not? Is that or getting involved on the lesser tool to make it better. Eduardo. -Mensaje original- De: Gary Gregory [mailto:[EMAIL PROTECTED] Enviado el: viernes, 03 de septiembre de 2004 1:59 Para: Jakarta Commons Developers List; Dion Gillard Asunto: RE: Moving from Bugzilla to JIRA On principle, I am not in favor of moving /away/ from Bugzilla, an open-source project, to Jira, a non-open-source project. It feels to me that this would send a negative message, as in: we are not supporting the open-source community. OTOH, this is software evolution at work. I have heard good things about JIRA, but not used it much beyond filing a couple of tickets vs. Maven. Gary -Original Message- From: Dion Gillard [mailto:[EMAIL PROTECTED] Sent: Thursday, September 02, 2004 15:40 To: Jakarta Commons Developers List Subject: Moving from Bugzilla to JIRA I've found out that the JIRA import process from Bugzilla can only import a whole project, and not components, and hence all of jakarta-commons has to go together. Does anyone still want to stay on Bugzilla? Do we need a vote for this? -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving from Bugzilla to JIRA
-1 on moving to JIRA. Martin Cooper has indicated there are people in infrastructure are willing to do a bugzilla upgrade. Just because bugzilla's UI is ugly and JIRA's is pretty is not a valid reason to switch to proprietary software in an OSS community. Regardless, many other bugzilla installations including Red Hat's demonstrate bugzilla is skinnable. I can read the Slashdot headlines now: Apache abandons Bugzilla in favor of proprietary software. IMO, this switch is bad for our community. David --- Paul Libbrecht [EMAIL PROTECTED] wrote: I'd also be +1 but I am a bit bothered by the political impact of depending on a commercial product as strong open-source veteran. Currently +0. If Bugzilla skins would exist (they are possible) and be used and usable, I think such discussion would be way more futile. Unfortunately, I haven't seen any. As of Scarab, I still haven't managed to get a demo-account to be opened for me on any demo-server... which is not a really good sign, I feel. paul PS: the bugzilla/jira opposition is a real feel for open-source can't do GUIs wich is really something a bit too widespread. PPS: I haven't done it but you can export all Bugzilla bugs of one product and only keep the ones for a given component, leaving quiet the bugzilla ones... so the need for a complete migration isn't really there except it takes more time to migrate a single component. Le 3 sept. 04, à 14:24, Henri Yandell a écrit : I'd like to be using JIRA rather than Bugzilla. Release planning feels possible in JIRA, whereas in Bugzilla it always feels like something so painful it is not worth the effort you'd have to put in. In fact, I'm currently using the Wiki to try to simulate the release process in JIRA :) +1 Hen On Fri, 3 Sep 2004, [iso-8859-1] Eduardo Sebastián Marco wrote: I think it should be necessary to have a vote, but I don't think like Gary does. I think the matter here is not whether we support opensource or not... Of course we do! I think the matter here is excelence. And in my opinion, if there's something actually better and it's avalaible, why not? Is that or getting involved on the lesser tool to make it better. Eduardo. -Mensaje original- De: Gary Gregory [mailto:[EMAIL PROTECTED] Enviado el: viernes, 03 de septiembre de 2004 1:59 Para: Jakarta Commons Developers List; Dion Gillard Asunto: RE: Moving from Bugzilla to JIRA On principle, I am not in favor of moving /away/ from Bugzilla, an open-source project, to Jira, a non-open-source project. It feels to me that this would send a negative message, as in: we are not supporting the open-source community. OTOH, this is software evolution at work. I have heard good things about JIRA, but not used it much beyond filing a couple of tickets vs. Maven. Gary -Original Message- From: Dion Gillard [mailto:[EMAIL PROTECTED] Sent: Thursday, September 02, 2004 15:40 To: Jakarta Commons Developers List Subject: Moving from Bugzilla to JIRA I've found out that the JIRA import process from Bugzilla can only import a whole project, and not components, and hence all of jakarta-commons has to go together. Does anyone still want to stay on Bugzilla? Do we need a vote for this? -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Moving from Bugzilla to JIRA
Hola, BTW, I'd be willing to help update/patch/skin our Bugzilla installation, and I bet I'm not the only one (hence the CC to infrastructure on this). Yoav Shapira Millennium Research Informatics -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Friday, September 03, 2004 9:24 AM To: Jakarta Commons Developers List Subject: Re: Moving from Bugzilla to JIRA -1 on moving to JIRA. Martin Cooper has indicated there are people in infrastructure are willing to do a bugzilla upgrade. Just because bugzilla's UI is ugly and JIRA's is pretty is not a valid reason to switch to proprietary software in an OSS community. Regardless, many other bugzilla installations including Red Hat's demonstrate bugzilla is skinnable. I can read the Slashdot headlines now: Apache abandons Bugzilla in favor of proprietary software. IMO, this switch is bad for our community. David --- Paul Libbrecht [EMAIL PROTECTED] wrote: I'd also be +1 but I am a bit bothered by the political impact of depending on a commercial product as strong open-source veteran. Currently +0. If Bugzilla skins would exist (they are possible) and be used and usable, I think such discussion would be way more futile. Unfortunately, I haven't seen any. As of Scarab, I still haven't managed to get a demo-account to be opened for me on any demo-server... which is not a really good sign, I feel. paul PS: the bugzilla/jira opposition is a real feel for open-source can't do GUIs wich is really something a bit too widespread. PPS: I haven't done it but you can export all Bugzilla bugs of one product and only keep the ones for a given component, leaving quiet the bugzilla ones... so the need for a complete migration isn't really there except it takes more time to migrate a single component. Le 3 sept. 04, à 14:24, Henri Yandell a écrit : I'd like to be using JIRA rather than Bugzilla. Release planning feels possible in JIRA, whereas in Bugzilla it always feels like something so painful it is not worth the effort you'd have to put in. In fact, I'm currently using the Wiki to try to simulate the release process in JIRA :) +1 Hen On Fri, 3 Sep 2004, [iso-8859-1] Eduardo Sebastián Marco wrote: I think it should be necessary to have a vote, but I don't think like Gary does. I think the matter here is not whether we support opensource or not... Of course we do! I think the matter here is excelence. And in my opinion, if there's something actually better and it's avalaible, why not? Is that or getting involved on the lesser tool to make it better. Eduardo. -Mensaje original- De: Gary Gregory [mailto:[EMAIL PROTECTED] Enviado el: viernes, 03 de septiembre de 2004 1:59 Para: Jakarta Commons Developers List; Dion Gillard Asunto: RE: Moving from Bugzilla to JIRA On principle, I am not in favor of moving /away/ from Bugzilla, an open-source project, to Jira, a non-open-source project. It feels to me that this would send a negative message, as in: we are not supporting the open-source community. OTOH, this is software evolution at work. I have heard good things about JIRA, but not used it much beyond filing a couple of tickets vs. Maven. Gary -Original Message- From: Dion Gillard [mailto:[EMAIL PROTECTED] Sent: Thursday, September 02, 2004 15:40 To: Jakarta Commons Developers List Subject: Moving from Bugzilla to JIRA I've found out that the JIRA import process from Bugzilla can only import a whole project, and not components, and hence all of jakarta-commons has to go together. Does anyone still want to stay on Bugzilla? Do we need a vote for this? -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments,
Re: Moving from Bugzilla to JIRA
Le 3 sept. 04, à 15:24, David Graham a écrit : Just because bugzilla's UI is ugly and JIRA's is pretty is not a valid reason to switch to proprietary software in an OSS community. Well, that's the bone question. The problem is not aesthetics, the gain in JIRA (for all of us who have used it) is readability and accessibility! (which means time, but also means people more easily posting, or...) paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Digester 1.6.0
-8 [X ] +1 I wholeheartedly support this release [ ] +0 I am in favour of this release but cannot give it my full recommendation [ ] -0 I have reservations concerning this release [ ] -1 The code should not be released as Digester 1.6.0 -- -- Jeanfrancois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31040] New: - [configuration] Absolute paths in build.xml
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31040. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31040 [configuration] Absolute paths in build.xml Summary: [configuration] Absolute paths in build.xml Product: Commons Version: Nightly Builds Platform: All OS/Version: All Status: NEW Severity: Minor Priority: Other Component: Configuration AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The build.xml file generated by Maven contains absolute paths (D:\dev\apache\jakarta-commons\configuration), it should use relative paths. Is this a Maven issue or did we miss something when generating the file ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31040] - [configuration] Absolute paths in build.xml
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31040. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31040 [configuration] Absolute paths in build.xml --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 14:30 --- This was actually a bug in the ant plugin: http://jira.codehaus.org/browse/MPANT-16 It has been fixed in the version 1.8.1 of the plugin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31041] New: - [configuration] Invalid resource names in XMLConfiguration generate a NPE
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31041.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=31041
[configuration] Invalid resource names in XMLConfiguration generate a NPE
Summary: [configuration] Invalid resource names in
XMLConfiguration generate a NPE
Product: Commons
Version: Nightly Builds
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Other
Component: Configuration
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
XMLConfiguration throws a NullPointerException if an invalid resource name is
passed to its constructor, it should throw a ConfigurationException explaining
the issue instead.
Fix suggested by Ben Hutchison:
private static File resourceURLToFile(String resource) {
URL confURL = XMLConfiguration.class.getClassLoader().getResource(resource);
if (confURL == null) {
confURL = ClassLoader.getSystemResource(resource);
}
if (confURL == null)
throw new IllegalArgumentException(Resource:+resource+ not found
thru context or system classloaders.);
return new File(confURL.getFile());
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31045] New: - Null handling in Insert, Update, and Delete
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31045.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=31045
Null handling in Insert, Update, and Delete
Summary: Null handling in Insert, Update, and Delete
Product: Commons
Version: unspecified
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: Major
Priority: Other
Component: DbUtils
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
While using the DbUtils to perform an insert or an update into DB2 v8 I ran into
a null issue. DbUtils uses the following to handle nulls. DB2 is requiring the
passing in of the EXACT column type to use setNull(i,Types.*). Using
Types.OTHER throws an exception (see after code).
DbUtils Code:
/**
* Fill the codePreparedStatement/code replacement parameters with
* the given objects.
* @param stmt
* @param params Query replacement parameters; codenull/code is a valid
* value to pass in.
* @throws SQLException
*/
protected void fillStatement(PreparedStatement stmt, Object[] params)
throws SQLException {
if (params == null) {
return;
}
for (int i = 0; i params.length; i++) {
if (params[i] != null) {
stmt.setObject(i + 1, params[i]);
} else {
stmt.setNull(i + 1, Types.OTHER);
}
}
}
Exception thrown:
COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver] CLI0123E SQL data type out of
range. SQLSTATE=HY004
at COM.ibm.db2.jdbc.app.SQLExceptionGenerator.throw_SQLException(Unknown
Source)
at COM.ibm.db2.jdbc.app.SQLExceptionGenerator.throw_SQLException(Unknown
Source)
at COM.ibm.db2.jdbc.app.SQLExceptionGenerator.check_return_code(Unknown Source)
at COM.ibm.db2.jdbc.app.DB2PreparedStatement.execute2(Unknown Source)
at COM.ibm.db2.jdbc.app.DB2PreparedStatement.executeUpdate(Unknown Source)
at PrepStmt.main(PrepStmt.java:56)
Code snippet that threw the exception:
Connection con = DriverManager.getConnection(url, uid, pswd);
PreparedStatement p = con.prepareStatement(insert into dac.person values (?,?));
p.setInt(1,0); // integer column, id thing
p.setNull(2,Types.OTHER); // pretend BLOB column. But it fails on anything.
//this one works for the blob column -- p.setBytes(2,null);
int x = p.executeUpdate();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31046] New: - [configuration] XMLConfiguration.addProperty doesn't create new child nodes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31046.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=31046
[configuration] XMLConfiguration.addProperty doesn't create new child nodes
Summary: [configuration] XMLConfiguration.addProperty doesn't
create new child nodes
Product: Commons
Version: Nightly Builds
Platform: All
OS/Version: All
Status: NEW
Severity: Critical
Priority: Other
Component: Configuration
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Issue reported by Ben Hutchison on the dev list:
XMLConfiguration.addProperty(key, Object) doesn't handle nest keys
properly.
In this loop logic, the full key name is broken into parts, and the DOM
tree is walked. However, if a branch mentioned in the key isn't there,
the loop incorrectly breaks out. Result is that eg addProperty(a.b)
doesn't actually add at a.b unless a b already exist. Old
version shown:
String[] nodes = parseElementNames(name);
Element element = document.getDocumentElement();
Element parent = element;
for (int i = 0; i nodes.length; i++) {
if (element == null)
break;// this is not right
**
parent = element;
String eName = nodes[i];
Element child = getChildElementWithName(eName, element);
element = child;
}
My tested fix:
Element element = document.getDocumentElement();
Element child = null;
for (int i = 0; i nodes.length; i++) {
child = getChildElementWithName(nodes[i], element);
if (child == null) {
child = document.createElement(nodes[i]);
element.appendChild(child);
}
element = child;
}
if (attName == null) {
CharacterData data = document.createTextNode(value.toString());
child.appendChild(data);
} else {
child.setAttribute(attName, value.toString());
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] Problems and shortcomings
Hi, thanks for your feedback, it definitely helps :) Hutchison, Ben wrote: 1. Build file script because it uses hardcode paths D:/.../etc/etc. Fix - use the basedir variable as below. Good point I didn't pay attention to this since the build.xml file is automatically generated by Maven. Consider using Maven instead until it's fixed. I filed a bug if you want to track this issue: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=31040 2. XMLConfiguration fails badly with NPE if an invalid system resource name passed to constructor. Loading issues have been reported with XMLConfiguration, this will be reworked. I filed a bug for this as well: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=31041 3. XMLConfiguration.addProperty(key, Object) makes improper downcast of Object to String. This will be fixed soon, this issue has been already reported in Bugzilla: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=30839 4 XMLConfiguration.addProperty(key, Object) doesn't handle nest keys properly. I'll add a test case for this, thanks for noticing it. Here is the related bug: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=31046 Also, not a bug as such, but I noticed that commons configuration have some pretty heavy library requirements. I only use the XML configuration, and I found by trial and error that I didn't need more over half of the stated dependencies. It would be nice if the configuration build or distribution process could split out some of the extensions and their dependencies so people looing for a lightweight solution can us it. You are right, and this is on my todo list :) The current dependency list generated by Maven isn't really helpful for end users, I plan to add a page specifying the core depencies and the extra dependencies needed for each configuration type. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31048] New: - [configuration] Dependencies documentation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31048. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31048 [configuration] Dependencies documentation Summary: [configuration] Dependencies documentation Product: Commons Version: Nightly Builds Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Configuration AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The current dependency list generated by Maven isn't really helpful for end users, it's rather intimidating actually for such a simple component. http://jakarta.apache.org/commons/configuration/dependencies.html We need a page specifying the core dependencies and the extra dependencies needed for each configuration type. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] Problems and shortcomings
Emmanuel Bourg wrote on Friday, September 03, 2004 5:00 PM: Hi, thanks for your feedback, it definitely helps :) Hutchison, Ben wrote: 1. Build file script because it uses hardcode paths D:/.../etc/etc. Fix - use the basedir variable as below. Good point I didn't pay attention to this since the build.xml file is automatically generated by Maven. Consider using Maven instead until it's fixed. I filed a bug if you want to track this issue: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=31040 Install and use the latest ant-plugin of Maven. Bug is fixed. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] Problems and shortcomings
Jörg Schaible wrote: Install and use the latest ant-plugin of Maven. Bug is fixed. How do you update a specific plugin once maven is installed ? I tried to specify the 1.8.1 version of the ant plugin in project.xml but it didn't work :( Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/configuration project.xml
ebourg 2004/09/03 08:22:17
Modified:configuration project.xml
Log:
Updated the dependencies on commons-logging and commons-beanutils
Removed simple-jndi
Moved myself to the developper list email update
Revision ChangesPath
1.27 +74 -76jakarta-commons/configuration/project.xml
Index: project.xml
===
RCS file: /home/cvs/jakarta-commons/configuration/project.xml,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- project.xml 16 Aug 2004 22:16:30 - 1.26
+++ project.xml 3 Sep 2004 15:22:17 - 1.27
@@ -34,7 +34,7 @@
various formats
/description
logo/images/logo.png/logo
-
+
urlhttp://jakarta.apache.org/commons/${pom.artifactId.substring(8)}//url
packageorg.apache.commons.${pom.artifactId.substring(8)}/package
@@ -43,7 +43,7 @@
urlhttp://jakarta.apache.org/url
logohttp://jakarta.apache.org/images/original-jakarta-logo.gif/logo
/organization
-
+
licenses
license
nameThe Apache Software License, Version 2.0/name
@@ -51,18 +51,18 @@
distributionrepo/distribution
/license
/licenses
-
+
gumpRepositoryIdjakarta/gumpRepositoryId
issueTrackingUrlhttp://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWamp;bug_status=ASSIGNEDamp;bug_status=REOPENEDamp;product=Commonsamp;component=Configuration/issueTrackingUrl
siteAddressjakarta.apache.org/siteAddress
siteDirectory/www/jakarta.apache.org/commons/${pom.artifactId.substring(8)}//siteDirectory
distributionDirectory/www/jakarta.apache.org/builds/jakarta-commons/${pom.artifactId.substring(8)}//distributionDirectory
-
+
repository
connectionscm:cvs:pserver:[EMAIL
PROTECTED]:/home/cvspublic:jakarta-commons/${pom.artifactId.substring(8)}/connection
urlhttp://cvs.apache.org/viewcvs/jakarta-commons/${pom.artifactId.substring(8)}//url
/repository
-
+
mailingLists
mailingList
nameCommons Dev List/name
@@ -80,7 +80,7 @@
branches
/branches
-
+
developers
developer
@@ -132,168 +132,166 @@
email[EMAIL PROTECTED]/email
organizationdunbarconsulting.org/organization
/developer
- /developers
-
- contributors
-contributor
+
+developer
nameEmmanuel Bourg/name
idebourg/id
- email[EMAIL PROTECTED]/email
-/contributor
+ email[EMAIL PROTECTED]/email
+/developer
+
+ /developers
+
+ contributors
+
contributor
nameOliver Heger/name
idoheger/id
email[EMAIL PROTECTED]/email
-/contributor
+/contributor
+
contributor
nameJouml;rg Schaible/name
idjschaible/id
email[EMAIL PROTECTED]/email
organizationElsag-Solutions AG/organization
timezone+1/timezone
-/contributor
+/contributor
+
contributor
nameKonstantin Shaposhnikov/name
idkshaposhnikov/id
email[EMAIL PROTECTED]/email
organizationscand.com/organization
/contributor
+
/contributors
-
+
dependencies
dependency
groupIdcommons-collections/groupId
- artifactIdcommons-collections/artifactId
+ artifactIdcommons-collections/artifactId
version3.0/version
- properties
+ properties
war.bundletrue/war.bundle
- /properties
+ /properties
/dependency
dependency
groupIdcommons-lang/groupId
- artifactIdcommons-lang/artifactId
+ artifactIdcommons-lang/artifactId
version2.0/version
- properties
+ properties
war.bundletrue/war.bundle
- /properties
+ /properties
/dependency
dependency
- groupIdcommons-logging/groupId
- artifactIdcommons-logging/artifactId
- version1.0.3/version
- properties
-war.bundletrue/war.bundle
- /properties
+ groupIddom4j/groupId
+ artifactIddom4j/artifactId
+ version1.4/version
/dependency
dependency
- groupIddom4j/groupId
- artifactIddom4j/artifactId
- version1.4/version
- properties
+ groupIdcommons-logging/groupId
+ artifactIdcommons-logging/artifactId
+ version1.0.4/version
+ properties
war.bundletrue/war.bundle
- /properties
+ /properties
/dependency
dependency
groupIdcommons-digester/groupId
- artifactIdcommons-digester/artifactId
+ artifactIdcommons-digester/artifactId
version1.5/version
- properties
+ properties
RE: [configuration] Problems and shortcomings
Emmanuel Bourg wrote on Friday, September 03, 2004 5:15 PM: Jörg Schaible wrote: Install and use the latest ant-plugin of Maven. Bug is fixed. How do you update a specific plugin once maven is installed ? I tried to specify the 1.8.1 version of the ant plugin in project.xml but it didn't work :( Unfortunately this does not work because of a bug in the plugin-plugin ;-) So you have to install the plugin manually: http://maven.apache.org/faq.html#DownloadPlugin - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/configuration build.xml
ebourg 2004/09/03 08:49:21
Modified:configuration build.xml
Log:
Removed absolute paths
Revision ChangesPath
1.8 +48 -81jakarta-commons/configuration/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons/configuration/build.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- build.xml 20 Jul 2004 11:08:36 - 1.7
+++ build.xml 3 Sep 2004 15:49:21 - 1.8
@@ -1,27 +1,33 @@
?xml version=1.0 encoding=UTF-8?
-!--build.xml generated by maven from project.xml version 1.0-rc1
- on date July 20 2004, time 1306--
+!--build.xml generated by maven from project.xml version 1.0-SNAPSHOT
+ on date September 3 2004, time 1745--
project default=jar name=commons-configuration basedir=.
- property name=defaulttargetdir
value=D:\dev\apache\jakarta-commons\configuration/target
+ property name=defaulttargetdir value=target
/property
- property name=libdir
value=D:\dev\apache\jakarta-commons\configuration/target/lib
+ property name=libdir value=target/lib
/property
- property name=classesdir
value=D:\dev\apache\jakarta-commons\configuration/target/classes
+ property name=classesdir value=target/classes
/property
- property name=testclassesdir
value=D:\dev\apache\jakarta-commons\configuration/target/test-classes
+ property name=testclassesdir value=target/test-classes
/property
- property name=testclassesdir
value=D:\dev\apache\jakarta-commons\configuration/target/test-classes
+ property name=testclassesdir value=target/test-classes
/property
- property name=testreportdir
value=D:\dev\apache\jakarta-commons\configuration/target/test-reports
+ property name=testreportdir value=target/test-reports
/property
property name=distdir value=dist
/property
property name=javadocdir value=dist/docs/api
/property
- property name=final.name value=commons-configuration-1.0-rc1
+ property name=final.name value=commons-configuration-1.0-SNAPSHOT
/property
+ path id=build.classpath
+fileset dir=${libdir}
+ include name=**/*.jar
+ /include
+/fileset
+ /path
target name=init description=o Initializes some properties
mkdir dir=${libdir}
/mkdir
@@ -29,6 +35,10 @@
equals arg2=only arg1=${build.sysclasspath}
/equals
/condition
+!--Test if JUNIT is present in ANT classpath--
+
+available property=Junit.present classname=junit.framework.Test
+/available
/target
target name=compile description=o Compile the code depends=get-deps
mkdir dir=${classesdir}
@@ -38,11 +48,7 @@
pathelement location=src/java
/pathelement
/src
- classpath
-fileset dir=${libdir}
- include name=*.jar
- /include
-/fileset
+ classpath refid=build.classpath
/classpath
/javac
copy todir=${classesdir}
@@ -51,40 +57,6 @@
/include
/fileset
/copy
-copy todir=${testclassesdir}
- fileset dir=conf
-include name=*.xml
-/include
- /fileset
-/copy
-copy todir=${testclassesdir}
- fileset dir=conf
-include name=testClasspath.properties
-/include
-include name=testdb.script
-/include
-include name=*.properties
-/include
- /fileset
-/copy
-mkdir dir=${testclassesdir}/org/apache/commons/configuration
-/mkdir
-copy todir=${testclassesdir}/org/apache/commons/configuration
- fileset dir=conf
-include name=test.properties
-/include
-include name=include.properties
-/include
- /fileset
-/copy
-mkdir dir=${testclassesdir}/config
-/mkdir
-copy todir=${testclassesdir}/config
- fileset dir=conf/config
-include name=**/*.properties
-/include
- /fileset
-/copy
/target
target name=jar description=o Create the jar depends=compile,test
jar jarfile=${defaulttargetdir}/${final.name}.jar excludes=**/package.html
basedir=${classesdir}
@@ -110,7 +82,7 @@
fail message=There were test failures.
/fail
/target
- target name=internal-test depends=compile-tests
+ target name=internal-test if=Junit.present
depends=junit-present,compile-tests
mkdir dir=${testreportdir}
/mkdir
junit dir=./ failureproperty=test.failure printSummary=yes fork=true
haltonerror=true
@@ -121,10 +93,8 @@
formatter usefile=false type=plain
/formatter
classpath
-fileset dir=${libdir}
- include name=*.jar
- /include
-/fileset
+path refid=build.classpath
+/path
pathelement
DO NOT REPLY [Bug 31040] - [configuration] Absolute paths in build.xml
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31040. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31040 [configuration] Absolute paths in build.xml [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 15:51 --- Fixed! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] Problems and shortcomings
Jörg Schaible wrote: Unfortunately this does not work because of a bug in the plugin-plugin ;-) So you have to install the plugin manually: http://maven.apache.org/faq.html#DownloadPlugin Thanks, it works fine now :) Eric if you read this, don't forget to update your plugin as well. Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31033] - All FTPEntryParser do not work with files 4GB
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31033. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31033 All FTPEntryParser do not work with files 4GB [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 15:58 --- Previously fixed. Please see resolution of issue 30345: http://issues.apache.org/bugzilla/show_bug.cgi?id=30345 Also, please verify against HEAD branch. *** This bug has been marked as a duplicate of 30345 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30345] - FTPFile.getSize() returns 0 on large files
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30345. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30345 FTPFile.getSize() returns 0 on large files [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 15:58 --- *** Bug 31033 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving from Bugzilla to JIRA
I'm happy to try out an upgrade to Bugzilla before I start campaigning that Jira is sufficiently better. Jira's Roadmap and Changelog are the two features that blow Bugzilla away for me. Attempting to do version management in Bugzilla was so frustrating that I simply gave up. Jira would also allow us to administer our own components and not have to ask infrastructure to add new version id's for component X etc. I'm not however convinced that Jakarta Commons is a good fit for Jira. I don't think they can handle us yet. The following is an example of a Commons like project in Jira. I encourage anyone who's not used Jira to go have a look at this link and get a feel for how easy it is to use, compared to the mess that is our bugzilla installation. http://issues.osjava.org:8080/jira/secure/BrowseProject.jspa?id=10010 As I have modelled each Commons-like component as a Component in Jira, it's hard to know how many there actually are. You also can't have separate versions for different components. Jira only have a two level project system. Project + Component, and Components are just a marker, so it's far too limited. I think Bugzilla is the same. We really need something in which Components are just projects within a larger projects. Hen On Fri, 3 Sep 2004, Emmanuel Bourg wrote: I prefer to stick with Bugzilla, for ethical and technical reasons. Bugzilla is good enough for my needs, I prefer to promote an open source product, and an upgrade of the version currently deployed on Nagoya is planned sooner or later. -1 on migrating [configuration] to JIRA. Emmanuel Bourg Dion Gillard wrote: I've found out that the JIRA import process from Bugzilla can only import a whole project, and not components, and hence all of jakarta-commons has to go together. Does anyone still want to stay on Bugzilla? Do we need a vote for this? - 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: Moving from Bugzilla to JIRA
Hola, Jira would also allow us to administer our own components and not have to ask infrastructure to add new version id's for component X etc. Many of us have that ability now: you just need to ask infrastructure for karma so you get the edit components link when you login to Bugzilla. For example, they haven't had to do any Tomcat component management for a long time, even though Tomcat has many sub-components and many versions, we take care of it ourselves and it's nearly zero effort. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving from Bugzilla to JIRA
+1 on moving from Bugzilla to JIRA. I've yet to meet an issue tracking system that didn't cause me issues, but JIRA clearly has more features to support planning, status assessment, and development. The Foundation already has free access to the product and source code and is already using it, so it's a rather moot point for me to object based on concerns I would have otherwise. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/configuration/xdocs changes.xml
ebourg 2004/09/03 09:36:21
Modified:configuration/src/java/org/apache/commons/configuration
XMLConfiguration.java
configuration/src/test/org/apache/commons/configuration
TestXMLConfiguration.java
configuration/xdocs changes.xml
Log:
Fixed Bug 30839 (ClassCastException in XMLConfiguration)
Revision ChangesPath
1.11 +4 -4
jakarta-commons/configuration/src/java/org/apache/commons/configuration/XMLConfiguration.java
Index: XMLConfiguration.java
===
RCS file:
/home/cvs/jakarta-commons/configuration/src/java/org/apache/commons/configuration/XMLConfiguration.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- XMLConfiguration.java 14 Aug 2004 11:32:06 - 1.10
+++ XMLConfiguration.java 3 Sep 2004 16:36:20 - 1.11
@@ -374,7 +374,7 @@
}
if (attName == null) {
-CharacterData data = document.createTextNode((String) value);
+CharacterData data = document.createTextNode(String.valueOf(value));
element.appendChild(data);
} else {
element.setAttribute(attName, (String) value);
@@ -427,10 +427,10 @@
Element child = document.createElement(nodes[nodes.length - 1]);
parent.appendChild(child);
if (attName == null) {
-CharacterData data = document.createTextNode((String) value);
+CharacterData data = document.createTextNode(String.valueOf(value));
child.appendChild(data);
} else {
-child.setAttribute(attName, (String) value);
+child.setAttribute(attName, String.valueOf(value));
}
}
1.9 +37 -24
jakarta-commons/configuration/src/test/org/apache/commons/configuration/TestXMLConfiguration.java
Index: TestXMLConfiguration.java
===
RCS file:
/home/cvs/jakarta-commons/configuration/src/test/org/apache/commons/configuration/TestXMLConfiguration.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- TestXMLConfiguration.java 16 Aug 2004 22:16:31 - 1.8
+++ TestXMLConfiguration.java 3 Sep 2004 16:36:21 - 1.9
@@ -44,7 +44,7 @@
conf = new XMLConfiguration(new File(testProperties));
}
-public void testGetProperty() throws Exception
+public void testGetProperty()
{
assertEquals(value, conf.getProperty(element));
}
@@ -66,7 +66,7 @@
conf.clearProperty(key);
assertNull(key, conf.getProperty(key));
assertNull(key, conf.getXmlProperty(key));
-
+
// test single element
conf.load();
key = clear.element;
@@ -83,21 +83,21 @@
key = [EMAIL PROTECTED];
assertNotNull(key, conf.getProperty(key));
assertNotNull(key, conf.getXmlProperty(key));
-
+
// test non-text/cdata element
conf.load();
key = clear.comment;
conf.clearProperty(key);
assertNull(key, conf.getProperty(key));
assertNull(key, conf.getXmlProperty(key));
-
+
// test cdata element
conf.load();
key = clear.cdata;
conf.clearProperty(key);
assertNull(key, conf.getProperty(key));
assertNull(key, conf.getXmlProperty(key));
-
+
// test multiple sibling elements
conf.load();
key = clear.list.item;
@@ -107,7 +107,7 @@
key = [EMAIL PROTECTED];
assertNotNull(key, conf.getProperty(key));
assertNotNull(key, conf.getXmlProperty(key));
-
+
// test multiple, disjoined elements
conf.load();
key = list.item;
@@ -120,7 +120,7 @@
// test non-leaf element
Object property = conf.getXmlProperty(clear);
assertNull(property);
-
+
// test non-existent element
property = conf.getXmlProperty(e);
assertNull(property);
@@ -128,29 +128,29 @@
// test non-existent element
property = conf.getXmlProperty([EMAIL PROTECTED]);
assertNull(property);
-
+
// test single element
property = conf.getXmlProperty(element);
assertNotNull(property);
assertTrue(property instanceof String);
assertEquals(value, property);
-
+
// test single attribute
property = conf.getXmlProperty([EMAIL PROTECTED]);
assertNotNull(property);
assertTrue(property instanceof String);
assertEquals(foo, property);
-
+
//
DO NOT REPLY [Bug 30839] - [configuration] ClassCastException in XMLConfiguration
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30839. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30839 [configuration] ClassCastException in XMLConfiguration [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 16:38 --- Tested and fixed! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving from Bugzilla to JIRA
Henri Yandell wrote: The following is an example of a Commons like project in Jira. I encourage anyone who's not used Jira to go have a look at this link and get a feel for how easy it is to use, compared to the mess that is our bugzilla installation. http://issues.osjava.org:8080/jira/secure/BrowseProject.jspa?id=10010 As I have modelled each Commons-like component as a Component in Jira, it's hard to know how many there actually are. You also can't have separate versions for different components. Henri, We would not map Jakarta Commons this way. Every JIRA project is a piece of code that is releasable, because as you suggest, a project has its own versions, components, changelog, and roadmap. Look at some of the Avalon/Merlin breakdowns to see how they each have their own JIRA project to get a feel for how this works. -- Serge Knystautas Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Moving from Bugzilla to JIRA
Eclipse is one large pile of code and their projects use Bugzilla, it would be interesting what their install looks like. Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jakarta-commons-sandbox commit privs for feedparser...
I'd like to give CVS commit to the sandbox to Brad Neuberg ([EMAIL PROTECTED]) who's working with me on getting a stable build of FeedParser ready. Thanks Kevin -- Please reply using PGP. http://peerfear.org/pubkey.asc NewsMonster - http://www.newsmonster.org/ Kevin A. Burton, Location - San Francisco, CA, Cell - 415.595.9965 AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 IRC - freenode.net #infoanarchy | #p2p-hackers | #newsmonster - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31045] - [dbutils] Null handling in Insert, Update, and Delete
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31045. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31045 [dbutils] Null handling in Insert, Update, and Delete [EMAIL PROTECTED] changed: What|Removed |Added Summary|Null handling in Insert,|[dbutils] Null handling in |Update, and Delete |Insert, Update, and Delete --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 18:13 --- The latest DbUtils code uses Types.VARCHAR which works with many different drivers. However, DB2 was not tested with Types.VARCHAR so it would be good if you could download the latest nightly build and test with that. If it still doesn't work with DB2 you can always override the fillStatement() method to provide custom handling. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31045] - [dbutils] Null handling in Insert, Update, and Delete
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31045. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31045 [dbutils] Null handling in Insert, Update, and Delete [EMAIL PROTECTED] changed: What|Removed |Added Version|unspecified |1.0 Final - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jakarta-commons-sandbox commit privs for feedparser...
Is Brad an apache committer already? If not, then we'll need to vote him in as a new committer. Which is usually based on activity in the community; patches+emails. Hen On Fri, 3 Sep 2004, Kevin A. Burton wrote: I'd like to give CVS commit to the sandbox to Brad Neuberg ([EMAIL PROTECTED]) who's working with me on getting a stable build of FeedParser ready. Thanks Kevin -- Please reply using PGP. http://peerfear.org/pubkey.asc NewsMonster - http://www.newsmonster.org/ Kevin A. Burton, Location - San Francisco, CA, Cell - 415.595.9965 AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 IRC - freenode.net #infoanarchy | #p2p-hackers | #newsmonster - 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]
cvs commit: jakarta-commons-sandbox/feedparser/src/java/org/apache/commons/feedparser/tools XMLCleanser.java XMLEncodingParser.java
burton 2004/09/03 12:46:47
Modified:feedparser TODO build.xml
feedparser/src/java/org/apache/commons/feedparser
FeedFilter.java FeedParser.java Main.java
RSSFeedParser.java
feedparser/src/java/org/apache/commons/feedparser/locate
AnchorParser.java ResourceExpander.java
feedparser/src/java/org/apache/commons/feedparser/test
TestFeedFilter.java TestFeedParser.java
feedparser/src/java/org/apache/commons/feedparser/tools
XMLCleanser.java XMLEncodingParser.java
Log:
don't use links if they are null
Revision ChangesPath
1.12 +1 -2 jakarta-commons-sandbox/feedparser/TODO
Index: TODO
===
RCS file: /home/cvs/jakarta-commons-sandbox/feedparser/TODO,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- TODO 31 Aug 2004 21:01:37 - 1.11
+++ TODO 3 Sep 2004 19:46:47 - 1.12
@@ -1,4 +1,5 @@
+- BUG: what happens when I put a comment after a UTF-16 BOM?!
- Support Base64 Atom values and the ability to enable them.
@@ -6,9 +7,7 @@
- Do we support multiple content items in Atom?
-
- We do not support multipart/alternative in the feedparser.
-
- Do we support atom:summary at ALL?! I don't think so...
1.7 +1 -0 jakarta-commons-sandbox/feedparser/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons-sandbox/feedparser/build.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- build.xml 2 Sep 2004 00:36:25 - 1.6
+++ build.xml 3 Sep 2004 19:46:47 - 1.7
@@ -121,6 +121,7 @@
formatter type=plain usefile=false/
+test name=org.apache.commons.feedparser.test.TestFeedFilter/
test name=org.apache.commons.feedparser.test.TestProbeLocator/
test name=org.apache.commons.feedparser.test.TestAtom/
test name=org.apache.commons.feedparser.test.TestFeedParserUTF8/
1.4 +37 -12
jakarta-commons-sandbox/feedparser/src/java/org/apache/commons/feedparser/FeedFilter.java
Index: FeedFilter.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/feedparser/src/java/org/apache/commons/feedparser/FeedFilter.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- FeedFilter.java 2 Sep 2004 01:19:55 - 1.3
+++ FeedFilter.java 3 Sep 2004 19:46:47 - 1.4
@@ -32,40 +32,65 @@
private static Pattern entity_pattern = Pattern.compile( ([a-zA-Z]+); );
-public static byte[] parse( byte[] bytes ) {
+public static byte[] parse( byte[] bytes )
+throws Exception {
-String content = new String( bytes );
+return parse( bytes, UTF-8 );
+
+}
+
+public static byte[] parse( byte[] bytes, String encoding )
+throws Exception {
+
+String content = new String( bytes, encoding );
+
+return parse( content, encoding );
+
+}
+
+public static byte[] parse( String content, String encoding )
+throws Exception {
//remove leading prolog...
-content = doRemoveLeadingProlog( content );
+content = doRemoveLeadingProlog( content, encoding );
content = doDecodeEntities( content );
-return content.getBytes();
-
-}
+return content.getBytes( encoding );
+}
+
/**
* Removing prolog whitespace, comments, and other garbage from the
* beginning of a feed.
*
* @author a href=mailto:[EMAIL PROTECTED]Kevin A. Burton/a
*/
-private static String doRemoveLeadingProlog( String content ) {
+private static String doRemoveLeadingProlog( String content, String encoding ) {
+
+//if we're a UTF-16 or UTF-32 feed we need to LEAVE the prolog because
+//it triggers a UTF-16 parse.
+if ( UTF-16.equals( encoding ) ||
+ UTF-32.equals( encoding ) )
+return content;
+
//move to the beginning of the first element or comment. When this is a
//processing instruction we will move to that
int begin = content.indexOf( );
-if ( begin 0 )
+if ( begin 0 ) {
content = content.substring( begin, content.length() );
+}
-//now skip to the XML processing instruction when necessary.
+//now skip to the XML processing instruction when
[IO] DOSFileFilter
Title: [IO] DOSFileFilter Is there any interest in including the attached file filter? It allows DOS style filtering using * and ? E.g. *test*.java~*~ to accept java test case backups Jason Anderson DOSFileFilter.java IMPORTANT NOTICEEmail from OOCL is confidential and may be legally privileged. If it is not intended for you, please delete it immediately unread. The internet cannot guarantee that this communication is free of viruses, interception or interference and anyone who communicates with us by email is taken to accept the risks in so doing. Without limitation, OOCL and its affiliates accept no liability whatsoever and howsoever arising in connection with the use of this email. Under no circumstances shall this email constitute a binding agreement to carry or for provision of carriage services by OOCL, which is subject to the availability of carrier's equipment and vessels and the terms and conditions of OOCL's standard bill of lading which is also available at http://www.oocl.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Moving from Bugzilla to JIRA
Henri, When commons moves to Jira, I would also recommend a project per component strategy. commons-digester, commons-betwixt, etc. This would make release management much easier. Tim O'Brien From: Serge Knystautas Sent: Fri 9/3/2004 12:57 PM To: Jakarta Commons Developers List Subject: Re: Moving from Bugzilla to JIRA Henri Yandell wrote: The following is an example of a Commons like project in Jira. I encourage anyone who's not used Jira to go have a look at this link and get a feel for how easy it is to use, compared to the mess that is our bugzilla installation. http://issues.osjava.org:8080/jira/secure/BrowseProject.jspa?id=10010 As I have modelled each Commons-like component as a Component in Jira, it's hard to know how many there actually are. You also can't have separate versions for different components. Henri, We would not map Jakarta Commons this way. Every JIRA project is a piece of code that is releasable, because as you suggest, a project has its own versions, components, changelog, and roadmap. Look at some of the Avalon/Merlin breakdowns to see how they each have their own JIRA project to get a feel for how this works. -- Serge Knystautas Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving from Bugzilla to JIRA
I am +1 to moving to Jira. Its a tool, not religion. And its easier to use than bugzilla IMHO. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jakarta-commons-sandbox commit privs for feedparser...
Hi Henri. I've been working with Kevin on the Feed Parser, submitting patches to him and having him incorporate them into the CVS tree; we recently decided that it would make sense to give me CVS access since I am making almost daily bug fixes and additions to the Feed Parser. About me: I am an open source developer living in San Francisco. I have been involved with the http://java.mozdev.org/blackconnectBlackConnect project, an effort to allow programmers to write Mozilla XPCOM components in Java; the http://java.mozdev.orgJava-Mozilla Integration project, an umbrella effort for open-source developers to work on turning Java into a full-fledged member of the Mozilla platform; the http://p2psockets.JXTA.orgP2P Sockets project, an initiative to port the existing web onto a peer-to-peer foundation and make working with JXTA easier; the Paper Airplane project, a browser plugin that empowers everone to be a writer as well as a reader; and submissions to the http://www.JXTA.orgJXTA and http://www.mozilla.orgMozilla projects. In the past I have worked on the OpenPortal project and the http://tinker.editthispage.com/FlashJavaFlash/Java Integration project. My weblog is at http://www.codinginparadise.org. Hope all is well, Brad Neuberg [EMAIL PROTECTED] At 12:33 PM 9/3/2004, Henri Yandell wrote: Is Brad an apache committer already? If not, then we'll need to vote him in as a new committer. Which is usually based on activity in the community; patches+emails. Hen On Fri, 3 Sep 2004, Kevin A. Burton wrote: I'd like to give CVS commit to the sandbox to Brad Neuberg ([EMAIL PROTECTED]) who's working with me on getting a stable build of FeedParser ready. Thanks Kevin -- Please reply using PGP. http://peerfear.org/pubkey.asc NewsMonster - http://www.newsmonster.org/ Kevin A. Burton, Location - San Francisco, CA, Cell - 415.595.9965 AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 IRC - freenode.net #infoanarchy | #p2p-hackers | #newsmonster - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IO] DOSFileFilter
Kind of. There was a similar suggestion of adding a WildcardFilter; which jakarta-oro currently has one of, so we didn't do it. For the IO 1.1 release, I'm planning to add a WildcardFilter that is not based on regexp, and will happily take submissions (especially with unit tests *hint* :) ). Best way to handle it is probably to make it a bugzilla entry for io, as I'm not planning to work on IO 1.1 until Lang 2.1 is getting near release time. Of course, anyone else is free to work on it, these are just my plans. Hen On Fri, 3 Sep 2004 [EMAIL PROTECTED] wrote: Is there any interest in including the attached file filter? It allows DOS style filtering using * and ? E.g. *test*.java~*~ to accept java test case backups Jason Anderson DOSFileFilter.java IMPORTANT NOTICE Email from OOCL is confidential and may be legally privileged. If it is not intended for you, please delete it immediately unread. The internet cannot guarantee that this communication is free of viruses, interception or interference and anyone who communicates with us by email is taken to accept the risks in so doing. Without limitation, OOCL and its affiliates accept no liability whatsoever and howsoever arising in connection with the use of this email. Under no circumstances shall this email constitute a binding agreement to carry or for provision of carriage services by OOCL, which is subject to the availability of carrier's equipment and vessels and the terms and conditions of OOCL's standard bill of lading which is also available at http://www.oocl.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
