Re: DO NOT REPLY [Bug 36529] - [lang] Fraction 0 to the zeroth power should throw an ArithmeticException
I agree with Brent, and we did discuss this a couple of years back: http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg23611.html On 9/6/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: 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=36529. 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=36529 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 04:39 --- The OP is correct in stating that 0^0 is an indeterminate form. However, in lang's defense, java.lang.Math.pow(0, 0) does return 1.0 based on the special case found in the javadoc comments: If the second argument is positive or negative zero, then the result is 1.0. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Release 1.1
Thanks for your thoughts, Stephen, especially the tip about the SVN handling. It's really cool we can now do things like that. Unthinkable with CVS. What you suggest is probably the best approach to avoid any more trouble on the subject. On 11.09.2005 00:50:40 Stephen Colebourne wrote: Jeremias Maerki wrote: Nothing from me, although I'd like to get something off my chest. I'm having trouble selling the benefit of using Commons IO inside the XML Graphics project. Well, it's only one person but still: The fact that CopyUtils is deprecated now and that all methods get moved (back!) to IOUtils tells him that Commons IO is not a good candidate as a dependency for the XML Graphics Commons components we're going to scrape together from Batik and FOP subprojects. We will probably end up duplicating the few things we absolutely need (IOUtils.closeQuietly(), CopyUtils.copy(InputStream, OutputStream) and CountingOutputStream) for the common components. Personally, I'm not averse to the use of commons projects by copying. Other committers have issues with this. If it does happen, I recommend using package scoped classes and recording in comments the SVN version you copied from. It also depends on the relative size of the project. If XML Graphics is quite a large project with a number of other dependencies, then having [io] as a dependency makes more sense than if XML Graphics is a very small library. Finally, on CopyUtils, I believe we got it wrong creating CopyUtils in the first place. It didn't fit in the library, wasn't about copying code (reading a stream was in IOUtils, but copying/writing was in CopyUtils!). Generally it was a bad call. This release gets it right by renaming the write methods to write() and putting everything in one place (better defining IOUtils as a class working with streams/readers/writers). Yes, this change will cause some pain, but its essential, and not really typical of the ongoing likelihood of change in the library. Stephen (forward this to your mailing list if you wish) Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36597] New: - [compress] CBZip2InputStream doesn't close the source stream
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=36597.
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=36597
Summary: [compress] CBZip2InputStream doesn't close the source
stream
Product: Commons
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Sandbox
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
Hi there,
I used compress component in sandbox via VFS component. And When I accessed
a tbz2 file via VFS, I could not remove the tbz2 file after closing stream.
I checked some codes and I found the reason of the phenomenon.
When a client program accessed a tbz2 file, the code uses TarFileSystem
( org.apache.commons.vfs.provider.tar.TarFileSystem ). TarFileSystem uses
CBZip2InputStream via Bzip2FileObject.wrapInputStream and the source
stream is created from FileInputStream like this:
class TarFileSystem
... snip ...
protected TarInputStream createTarFile(final File file) throws
FileSystemException
... snip ...
else if (tbz2.equalsIgnoreCase(getRootName().getScheme()))
{
return new TarInputStream(Bzip2FileObject.wrapInputStream(
file.getAbsolutePath(), new FileInputStream(file)));
}
I think CBZip2InputStream should close source stream like BufferedInputStream
and FilteredInputStream.
Could you please consider to close source stream in CBZip2InputStream#close() ?
Thanks,
Hiroki
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36597] - [compress] CBZip2InputStream doesn't close the source stream
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=36597. 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=36597 --- Additional Comments From [EMAIL PROTECTED] 2005-09-11 11:35 --- Created an attachment (id=16360) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16360action=view) [PATCH] patch to fix commons compress CBZip2InputStream close a source stream I tried to create a patch of my suggestion to fix CBZip2InputStream. If you have an interest of it, please check and consider to use it. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-javaflow (in module jakarta-commons-sandbox) failed
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-javaflow has an issue affecting its community integration. This issue affects 4 projects, and has been outstanding for 16 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-javaflow : Java XML Framework - cocoon-block-mail : Java XML Framework - cocoon-block-scratchpad : Java XML Framework - commons-javaflow : Commons Javaflow Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-javaflow/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-javaflow-11092005.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/javaflow/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/javaflow/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/javaflow/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-javaflow/gump_work/build_jakarta-commons-sandbox_commons-javaflow.html Work Name: build_jakarta-commons-sandbox_commons-javaflow (Type: Build) Work ended in a state of : Failed Elapsed: 7 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/javaflow] CLASSPATH: /opt/jdk1.4/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-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/io/dist/jakarta-commons-io-11092005.jar:/usr/local/gump/public/workspace/jakarta-commons-sandbox/jci/target/commons-jci-11092005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-11092005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-11092005.jar:/usr/local/gump/public/workspace/jakarta-jmeter/lib/xstream-1.1.2.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar - |_| |_\__,_|\_/\___|_||_| v. 1.0.2 build:start: java:prepare-filesystem: [mkdir] Created dir: /x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/classes java:compile: [echo] Compiling to /x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/classes [echo] == NOTE: Targetting JVM 1.4, classes will not run on earlier JVMs == [javac] Compiling 28 source files to /x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/classes java:jar-resources: test:prepare-filesystem: [mkdir] Created dir: /x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/test-classes [mkdir] Created dir: /x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/test-reports test:test-resources: test:compile: [javac] Compiling 11 source files to /x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/test-classes /x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/src/test/org/apache/commons/javaflow/ContinuationTests.java:21: cannot resolve symbol symbol : class NewObject location: package testcode import org.apache.commons.javaflow.testcode.NewObject; ^ /x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/src/test/org/apache/commons/javaflow/ContinuationTests.java:91: cannot resolve symbol symbol : class NewObject location: class org.apache.commons.javaflow.ContinuationTests Continuation c = Continuation.startWith(new NewObject()); ^ 2 errors BUILD FAILED File.. /home/gump/.maven/cache/maven-test-plugin-1.6.2/plugin.jelly Element... javac Line.. 52 Column 46 Compile
[EMAIL PROTECTED]: Project commons-javaflow (in module jakarta-commons-sandbox) failed
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-javaflow has an issue affecting its community integration. This issue affects 4 projects, and has been outstanding for 16 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-javaflow : Java XML Framework - cocoon-block-mail : Java XML Framework - cocoon-block-scratchpad : Java XML Framework - commons-javaflow : Commons Javaflow Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-javaflow/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-javaflow-11092005.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/javaflow/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/javaflow/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/javaflow/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-javaflow/gump_work/build_jakarta-commons-sandbox_commons-javaflow.html Work Name: build_jakarta-commons-sandbox_commons-javaflow (Type: Build) Work ended in a state of : Failed Elapsed: 7 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/javaflow] CLASSPATH: /opt/jdk1.4/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-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/io/dist/jakarta-commons-io-11092005.jar:/usr/local/gump/public/workspace/jakarta-commons-sandbox/jci/target/commons-jci-11092005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-11092005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-11092005.jar:/usr/local/gump/public/workspace/jakarta-jmeter/lib/xstream-1.1.2.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar - |_| |_\__,_|\_/\___|_||_| v. 1.0.2 build:start: java:prepare-filesystem: [mkdir] Created dir: /x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/classes java:compile: [echo] Compiling to /x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/classes [echo] == NOTE: Targetting JVM 1.4, classes will not run on earlier JVMs == [javac] Compiling 28 source files to /x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/classes java:jar-resources: test:prepare-filesystem: [mkdir] Created dir: /x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/test-classes [mkdir] Created dir: /x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/test-reports test:test-resources: test:compile: [javac] Compiling 11 source files to /x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/test-classes /x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/src/test/org/apache/commons/javaflow/ContinuationTests.java:21: cannot resolve symbol symbol : class NewObject location: package testcode import org.apache.commons.javaflow.testcode.NewObject; ^ /x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/src/test/org/apache/commons/javaflow/ContinuationTests.java:91: cannot resolve symbol symbol : class NewObject location: class org.apache.commons.javaflow.ContinuationTests Continuation c = Continuation.startWith(new NewObject()); ^ 2 errors BUILD FAILED File.. /home/gump/.maven/cache/maven-test-plugin-1.6.2/plugin.jelly Element... javac Line.. 52 Column 46 Compile
[EMAIL PROTECTED]: Project commons-jelly (in module commons-jelly) failed
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 has an issue affecting its community integration. This issue affects 43 projects, and has been outstanding for 13 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 : Commons Jelly - commons-jelly-tags-ant : Commons Jelly - commons-jelly-tags-antlr : Commons Jelly - commons-jelly-tags-avalon : Commons Jelly - commons-jelly-tags-bean : Commons Jelly - commons-jelly-tags-beanshell : Commons Jelly - commons-jelly-tags-betwixt : Commons Jelly - commons-jelly-tags-bsf : Commons Jelly - commons-jelly-tags-define : Commons Jelly - commons-jelly-tags-dynabean : Commons Jelly - commons-jelly-tags-email : Commons Jelly - commons-jelly-tags-fmt : Commons Jelly - commons-jelly-tags-html : Commons Jelly - commons-jelly-tags-http : Commons Jelly - commons-jelly-tags-interaction : Commons Jelly - commons-jelly-tags-jetty : Commons Jelly - commons-jelly-tags-jface : Commons Jelly - commons-jelly-tags-jms : Commons Jelly - commons-jelly-tags-jmx : Commons Jelly - commons-jelly-tags-jsl : Commons Jelly - commons-jelly-tags-junit : Commons Jelly - commons-jelly-tags-log : Commons Jelly - commons-jelly-tags-memory : Commons Jelly - commons-jelly-tags-ojb : Commons Jelly - commons-jelly-tags-quartz : Commons Jelly - commons-jelly-tags-regexp : Commons Jelly - commons-jelly-tags-sql : Commons Jelly - commons-jelly-tags-swing : Commons Jelly - commons-jelly-tags-swt : Commons Jelly - commons-jelly-tags-threads : Commons Jelly - commons-jelly-tags-util : Commons Jelly - commons-jelly-tags-validate : Commons Jelly - commons-jelly-tags-velocity : Commons Jelly - commons-jelly-tags-xml : Commons Jelly - commons-jelly-tags-xmlunit : Commons Jelly - commons-latka : Functional Testing Suite - geronimo : Apache Geronimo, the J2EE server project of the Apache Softw... - jaxme2 - jaxmeapi - jaxmepm - jaxmexs - maven : Project Management Tools - maven-bootstrap : Project Management Tools Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-11092005.jar] identifier set to project name -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for property maven.jar.servletapi. -DEBUG- Dependency on jakarta-taglibs-standard exists, no need to add for property maven.jar.jstl. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly/gump_work/build_commons-jelly_commons-jelly.html Work Name: build_commons-jelly_commons-jelly (Type: Build) Work ended in a state of : Failed Elapsed: 1 min 1 sec Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly] CLASSPATH:
[EMAIL PROTECTED]: Project commons-jelly (in module commons-jelly) failed
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 has an issue affecting its community integration. This issue affects 43 projects, and has been outstanding for 13 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 : Commons Jelly - commons-jelly-tags-ant : Commons Jelly - commons-jelly-tags-antlr : Commons Jelly - commons-jelly-tags-avalon : Commons Jelly - commons-jelly-tags-bean : Commons Jelly - commons-jelly-tags-beanshell : Commons Jelly - commons-jelly-tags-betwixt : Commons Jelly - commons-jelly-tags-bsf : Commons Jelly - commons-jelly-tags-define : Commons Jelly - commons-jelly-tags-dynabean : Commons Jelly - commons-jelly-tags-email : Commons Jelly - commons-jelly-tags-fmt : Commons Jelly - commons-jelly-tags-html : Commons Jelly - commons-jelly-tags-http : Commons Jelly - commons-jelly-tags-interaction : Commons Jelly - commons-jelly-tags-jetty : Commons Jelly - commons-jelly-tags-jface : Commons Jelly - commons-jelly-tags-jms : Commons Jelly - commons-jelly-tags-jmx : Commons Jelly - commons-jelly-tags-jsl : Commons Jelly - commons-jelly-tags-junit : Commons Jelly - commons-jelly-tags-log : Commons Jelly - commons-jelly-tags-memory : Commons Jelly - commons-jelly-tags-ojb : Commons Jelly - commons-jelly-tags-quartz : Commons Jelly - commons-jelly-tags-regexp : Commons Jelly - commons-jelly-tags-sql : Commons Jelly - commons-jelly-tags-swing : Commons Jelly - commons-jelly-tags-swt : Commons Jelly - commons-jelly-tags-threads : Commons Jelly - commons-jelly-tags-util : Commons Jelly - commons-jelly-tags-validate : Commons Jelly - commons-jelly-tags-velocity : Commons Jelly - commons-jelly-tags-xml : Commons Jelly - commons-jelly-tags-xmlunit : Commons Jelly - commons-latka : Functional Testing Suite - geronimo : Apache Geronimo, the J2EE server project of the Apache Softw... - jaxme2 - jaxmeapi - jaxmepm - jaxmexs - maven : Project Management Tools - maven-bootstrap : Project Management Tools Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-11092005.jar] identifier set to project name -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for property maven.jar.servletapi. -DEBUG- Dependency on jakarta-taglibs-standard exists, no need to add for property maven.jar.jstl. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly/gump_work/build_commons-jelly_commons-jelly.html Work Name: build_commons-jelly_commons-jelly (Type: Build) Work ended in a state of : Failed Elapsed: 1 min 1 sec Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly] CLASSPATH:
svn commit: r280140 - in /jakarta/commons/sandbox/compress/trunk/src: java/org/apache/commons/compress/bzip2/CBZip2InputStream.java test/org/apache/commons/compress/bzip2/test/BzipTestCase.java
Author: imario
Date: Sun Sep 11 07:01:25 2005
New Revision: 280140
URL: http://svn.apache.org/viewcvs?rev=280140view=rev
Log:
PR: 36597
Submitted by: Hiroki Ata hiroki.ata -at- mail.com
underlaying inputStream wasnt correctly closed.
Thanks for the patch!
Modified:
jakarta/commons/sandbox/compress/trunk/src/java/org/apache/commons/compress/bzip2/CBZip2InputStream.java
jakarta/commons/sandbox/compress/trunk/src/test/org/apache/commons/compress/bzip2/test/BzipTestCase.java
Modified:
jakarta/commons/sandbox/compress/trunk/src/java/org/apache/commons/compress/bzip2/CBZip2InputStream.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/compress/trunk/src/java/org/apache/commons/compress/bzip2/CBZip2InputStream.java?rev=280140r1=280139r2=280140view=diff
==
---
jakarta/commons/sandbox/compress/trunk/src/java/org/apache/commons/compress/bzip2/CBZip2InputStream.java
(original)
+++
jakarta/commons/sandbox/compress/trunk/src/java/org/apache/commons/compress/bzip2/CBZip2InputStream.java
Sun Sep 11 07:01:25 2005
@@ -624,6 +624,16 @@
private void bsFinishedWithStream()
{
+if (m_input != null)
+{
+try
+{
+m_input.close();
+}
+catch ( IOException e )
+{
+}
+}
m_input = null;
}
@@ -967,6 +977,6 @@
public void close() throws IOException
{
-m_input.close();
+ bsFinishedWithStream();
}
}
Modified:
jakarta/commons/sandbox/compress/trunk/src/test/org/apache/commons/compress/bzip2/test/BzipTestCase.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/compress/trunk/src/test/org/apache/commons/compress/bzip2/test/BzipTestCase.java?rev=280140r1=280139r2=280140view=diff
==
---
jakarta/commons/sandbox/compress/trunk/src/test/org/apache/commons/compress/bzip2/test/BzipTestCase.java
(original)
+++
jakarta/commons/sandbox/compress/trunk/src/test/org/apache/commons/compress/bzip2/test/BzipTestCase.java
Sun Sep 11 07:01:25 2005
@@ -83,6 +83,30 @@
forceDelete( outputFile );
}
+public void testCBZip2InputStreamClose()
+throws Exception
+{
+final InputStream input = getInputStream( asf-logo-huge.tar.bz2 );
+final File outputFile = getOutputFile( .tar.bz2 );
+final OutputStream output = new FileOutputStream( outputFile );
+copy( input, output );
+shutdownStream( input );
+shutdownStream( output );
+assertTrue( Check output file exists. , outputFile.exists() );
+final InputStream input2 = new FileInputStream( outputFile );
+final InputStream packedInput = getPackedInput( input2 );
+shutdownStream( packedInput );
+try
+{
+input2.read();
+assertTrue(Source input stream is still opened., false);
+} catch ( Exception e )
+{
+// Read closed stream.
+}
+forceDelete( outputFile );
+}
+
/**
* Copy bytes from an codeInputStream/code to an
codeOutputStream/code.
*/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36597] - [compress] CBZip2InputStream doesn't close the source stream
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=36597. 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=36597 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-09-11 16:03 --- Didnt you use the svn head version for this patch? http://svn.apache.org/repos/asf/jakarta/commons/sandbox/compress/trunk There were already a fix for this, though it cased a NPE, so I applied your patch and now it works like a charm. Thanks for the patch! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r280141 - in /jakarta/commons/proper/vfs/trunk: RELEASE_NOTES.txt build.xml project.xml xdocs/download.xml
Author: imario
Date: Sun Sep 11 07:15:15 2005
New Revision: 280141
URL: http://svn.apache.org/viewcvs?rev=280141view=rev
Log:
fix: changed documentation to use latest commons-compress
Modified:
jakarta/commons/proper/vfs/trunk/RELEASE_NOTES.txt
jakarta/commons/proper/vfs/trunk/build.xml
jakarta/commons/proper/vfs/trunk/project.xml
jakarta/commons/proper/vfs/trunk/xdocs/download.xml
Modified: jakarta/commons/proper/vfs/trunk/RELEASE_NOTES.txt
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/vfs/trunk/RELEASE_NOTES.txt?rev=280141r1=280140r2=280141view=diff
==
--- jakarta/commons/proper/vfs/trunk/RELEASE_NOTES.txt (original)
+++ jakarta/commons/proper/vfs/trunk/RELEASE_NOTES.txt Sun Sep 11 07:15:15 2005
@@ -1,5 +1,9 @@
2005-
+bzip:
+changed documentation to use latest commons-compress.
+
+
filesystems:
fix: avoid creation of filesystem if they use the same options
Modified: jakarta/commons/proper/vfs/trunk/build.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/vfs/trunk/build.xml?rev=280141r1=280140r2=280141view=diff
==
--- jakarta/commons/proper/vfs/trunk/build.xml (original)
+++ jakarta/commons/proper/vfs/trunk/build.xml Sun Sep 11 07:15:15 2005
@@ -176,8 +176,8 @@
get dest=${libdir}/commons-logging-1.0.4.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven/commons-logging/jars/commons-logging-1.0.4.jar;
/get
-get dest=${libdir}/commons-compress-20040530.jar
usetimestamp=true ignoreerrors=true
-
src=http://www.ibiblio.org/maven/commons-compress/jars/commons-compress-20040530.jar;
+get dest=${libdir}/commons-compress-20050911.jar
usetimestamp=true ignoreerrors=true
+
src=http://www.ibiblio.org/maven/commons-compress/jars/commons-compress-20050911.jar;
/get
get dest=${libdir}/commons-collections-3.1.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven/commons-collections/jars/commons-collections-3.1.jar;
Modified: jakarta/commons/proper/vfs/trunk/project.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/vfs/trunk/project.xml?rev=280141r1=280140r2=280141view=diff
==
--- jakarta/commons/proper/vfs/trunk/project.xml (original)
+++ jakarta/commons/proper/vfs/trunk/project.xml Sun Sep 11 07:15:15 2005
@@ -112,7 +112,7 @@
dependency
groupIdcommons-compress/groupId
artifactIdcommons-compress/artifactId
-version20040530/version
+version20050911/version
/dependency
dependency
Modified: jakarta/commons/proper/vfs/trunk/xdocs/download.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/vfs/trunk/xdocs/download.xml?rev=280141r1=280140r2=280141view=diff
==
--- jakarta/commons/proper/vfs/trunk/xdocs/download.xml (original)
+++ jakarta/commons/proper/vfs/trunk/xdocs/download.xml Sun Sep 11 07:15:15 2005
@@ -106,13 +106,13 @@
tr
td
a
href=http://jakarta.apache.org/commons/sandbox/compress/;Commons Compress/a
-Nightly build 20040530
+Nightly build 20050911
br/
There are no other nightlies than the one I created
for maven, so please download it from the
link below until this changes:
br/
-a
href=http://www.ibiblio.org/maven/commons-compress/jars/commons-compress-20040530.jar;
-
http://www.ibiblio.org/maven/commons-compress/jars/commons-compress-20040530.jar/a
+a
href=http://www.ibiblio.org/maven/commons-compress/jars/commons-compress-20050911.jar;
+
http://www.ibiblio.org/maven/commons-compress/jars/commons-compress-20050911.jar/a
/td
tdtar, bz2/td
/tr
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36597] - [compress] CBZip2InputStream doesn't close the source stream
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=36597. 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=36597 --- Additional Comments From [EMAIL PROTECTED] 2005-09-11 18:01 --- Thank you for checking this report quickly. And I'm so sorry I didn't check svn-repository. I think commons-compress is managed by CVS-repository to see the following page and the page figures CVS-repository for documentation. http://jakarta.apache.org/commons/sandbox/compress/ I should check the following page first. http://jakarta.apache.org/site/cvsindex.html I will check svn when I filed a new bug . ( I confirmed the fix is merged, so please close this bug. ) Thanks again ! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r280151 - /jakarta/commons/sandbox/compress/trunk/project.xml
Author: imario Date: Sun Sep 11 09:58:56 2005 New Revision: 280151 URL: http://svn.apache.org/viewcvs?rev=280151view=rev Log: added siteAddress and issueTrackingUrl Modified: jakarta/commons/sandbox/compress/trunk/project.xml Modified: jakarta/commons/sandbox/compress/trunk/project.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/sandbox/compress/trunk/project.xml?rev=280151r1=280150r2=280151view=diff == --- jakarta/commons/sandbox/compress/trunk/project.xml (original) +++ jakarta/commons/sandbox/compress/trunk/project.xml Sun Sep 11 09:58:56 2005 @@ -25,6 +25,8 @@ Commons Compress is a component that contains Tar, Zip and BZip2 packages. /description currentVersion0.1-dev/currentVersion + issueTrackingUrlhttp://issues.apache.org/bugzilla//issueTrackingUrl + siteAddresscvs.apache.org/siteAddress logo/logo versions - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36597] - [compress] CBZip2InputStream doesn't close the source stream
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=36597. 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=36597 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Additional Comments From [EMAIL PROTECTED] 2005-09-11 19:00 --- No problem. I updated the website, though it might take some time until you can see the changes. Thanks! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r280152 - in /jakarta/commons/sandbox/id/trunk: ./ src/java/org/apache/commons/id/uuid/ src/java/org/apache/commons/id/uuid/clock/ src/java/org/apache/commons/id/uuid/state/
Author: psteitz
Date: Sun Sep 11 10:15:08 2005
New Revision: 280152
URL: http://svn.apache.org/viewcvs?rev=280152view=rev
Log:
Javadoc only.
Change UUID referenced to RFC 4122.
PR# 35820
Submitted by Jukka Zitting
Also fixed numerous javadoc errors.
Modified:
jakarta/commons/sandbox/id/trunk/project.xml
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/Bytes.java
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/UUID.java
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/UUIDFormatException.java
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/VersionFourGenerator.java
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/VersionOneGenerator.java
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/clock/Clock.java
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/clock/SystemClockImpl.java
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/clock/ThreadClockImpl.java
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/clock/package.html
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/package.html
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/state/InMemoryStateImpl.java
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/state/ReadOnlyResourceStateImpl.java
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/state/ReadWriteFileStateImpl.java
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/state/State.java
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/state/StateHelper.java
Modified: jakarta/commons/sandbox/id/trunk/project.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/id/trunk/project.xml?rev=280152r1=280151r2=280152view=diff
==
--- jakarta/commons/sandbox/id/trunk/project.xml (original)
+++ jakarta/commons/sandbox/id/trunk/project.xml Sun Sep 11 10:15:08 2005
@@ -73,7 +73,7 @@
developer
namePhil Steitz/name
idpsteitz/id
- email[EMAIL PROTECTED]/email
+ emailpsteitz at apache dot org/email
organization/organization
timezone-9/timezone
roles
@@ -103,12 +103,6 @@
/developers
contributors
- contributor
- nameRory Winston/name
- idrwinston/id
- email[EMAIL PROTECTED]/email
- organization/organization
- /contributor
contributor
nameEric Crampton/name
email/email
@@ -119,6 +113,15 @@
email/email
organization/organization
/contributor
+ contributor
+ nameRory Winston/name
+ idrwinston/id
+ email[EMAIL PROTECTED]/email
+ organization/organization
+ /contributor
+ contributor
+ nameJukka Zitting/name
+ /contributor
/contributors
dependencies
Modified:
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/Bytes.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/Bytes.java?rev=280152r1=280151r2=280152view=diff
==
---
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/Bytes.java
(original)
+++
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/Bytes.java
Sun Sep 11 10:15:08 2005
@@ -21,7 +21,6 @@
*
* @author Commons-Id Team
* @version $Id$
- * [EMAIL PROTECTED] http://jakarta.apache.org/turbine/turbine-2.3/}
*/
public final class Bytes {
Modified:
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/UUID.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/UUID.java?rev=280152r1=280151r2=280152view=diff
==
---
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/UUID.java
(original)
+++
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/UUID.java
Sun Sep 11 10:15:08 2005
@@ -27,11 +27,10 @@
/**
- * pcodeUUID/code represents a Universally Unique Identifier per IETF
- * Draft specification. For more information regarding the IETF Draft UUID
- * specification/p
- *
- * pSee:
http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-01.txt/p
+ * pcodeUUID/code represents a Universally Unique Identifier per RFC
4122.
+ * See the a href=ftp://ftp.rfc-editor.org/in-notes/rfc4122.txt;RFC 4122:
+ * A Universally Unique IDentifier (UUID) URN Namespace/a
+ * for more information./p
*
* @author Commons-Id Team
* @version $Revision$ $Date$
@@ -252,7 +251,7 @@
DO NOT REPLY [Bug 35820] - [id] Change UUID referenced to RFC 4122
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=35820. 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=35820 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-09-11 19:15 --- Patch applied. Thanks! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r280153 - /jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/UUID.java
Author: psteitz
Date: Sun Sep 11 10:22:36 2005
New Revision: 280153
URL: http://svn.apache.org/viewcvs?rev=280153view=rev
Log:
Modified UUID to include the offending UUID value when throwing
UUIDFormatException.
PR# 36566
Reported by John Gregg
Patch Submitted by Jukka Zitting
Modified:
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/UUID.java
Modified:
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/UUID.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/UUID.java?rev=280153r1=280152r2=280153view=diff
==
---
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/UUID.java
(original)
+++
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/UUID.java
Sun Sep 11 10:22:36 2005
@@ -160,13 +160,13 @@
//Check for 36 char length
if (leanString.length() != UUID_FORMATTED_LENGTH) {
- throw new UUIDFormatException();
+ throw new UUIDFormatException(uuidString);
}
//Check for 5 fields
StringTokenizer tok = new StringTokenizer(leanString, -);
if ( tok.countTokens() != TOKENS_IN_UUID ) {
- throw new UUIDFormatException();
+ throw new UUIDFormatException(uuidString);
}
//Remove the - from the formatted string and test token sizes
@@ -176,7 +176,7 @@
while (tok.hasMoreTokens()) {
token = tok.nextToken();
if (token.length() != TOKEN_LENGTHS[count++]) {
- throw new UUIDFormatException();
+ throw new UUIDFormatException(uuidString);
}
buf.append(token);
}
@@ -186,7 +186,7 @@
char[] chars = buf.toString().toCharArray();
tmpUUID = new UUID(Hex.decodeHex(chars));
} catch (DecoderException de) {
- throw new UUIDFormatException(de.getMessage());
+ throw new UUIDFormatException(uuidString + : +
de.getMessage());
}
return tmpUUID;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36566] - [id] UUID should include the offending UUID value when throwing UUIDFormatException
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=36566. 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=36566 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-09-11 19:23 --- Patch applied. Thanks! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r280162 - in /jakarta/commons/sandbox/id/trunk/xdocs: navigation.xml uuid.xml
Author: psteitz Date: Sun Sep 11 11:02:29 2005 New Revision: 280162 URL: http://svn.apache.org/viewcvs?rev=280162view=rev Log: Fixed formatting, changed reference to point to UUID RFC 4122, added nav link to svn. Modified: jakarta/commons/sandbox/id/trunk/xdocs/navigation.xml jakarta/commons/sandbox/id/trunk/xdocs/uuid.xml Modified: jakarta/commons/sandbox/id/trunk/xdocs/navigation.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/sandbox/id/trunk/xdocs/navigation.xml?rev=280162r1=280161r2=280162view=diff == --- jakarta/commons/sandbox/id/trunk/xdocs/navigation.xml (original) +++ jakarta/commons/sandbox/id/trunk/xdocs/navigation.xml Sun Sep 11 11:02:29 2005 @@ -19,9 +19,11 @@ titleCommons#xA0;Id/title body menu name=Commons#xA0;Id -item name=Overview href=/index.html / -item name=API#xA0;Documentation href=/apidocs/index.html/ -item name=Downloads href=/downloads.html/ +item name=Overviewhref=/index.html / +item name=API#xA0;Documentation href=/apidocs/index.html/ +item name=Source Repository (current) + href=http://svn.apache.org/viewcvs.cgi/jakarta/commons/sandbox/id/trunk/ +item name=Downloads href=/downloads.html/ /menu common-menus; /body Modified: jakarta/commons/sandbox/id/trunk/xdocs/uuid.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/sandbox/id/trunk/xdocs/uuid.xml?rev=280162r1=280161r2=280162view=diff == --- jakarta/commons/sandbox/id/trunk/xdocs/uuid.xml (original) +++ jakarta/commons/sandbox/id/trunk/xdocs/uuid.xml Sun Sep 11 11:02:29 2005 @@ -24,36 +24,48 @@ body section name=Overview p - A Universally Unique Identifier (UUID) is a 128-bit identifier described in the - a href=http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-04.txt;IETF Draft Uuid Specification/a. - Generators for versions 1,3,4 and 5 UUIDapos;s are provided. The value held in a UUID is represented - by a specific hexadecimal format of the binary fields. An example UUID string representation is: - F81D4FAE-7DEC-11D0-A765-00A0C91E6BF6. A cautionary note: there is no standard regarding binary - representation of a UUID other than its string format. + A Universally Unique Identifier (UUID) is a 128-bit identifier described in + Internet Engineering Task Force + a href=ftp://ftp.rfc-editor.org/in-notes/rfc4122.txt;RFC 4122: + A Universally Unique IDentifier (UUID) URN Namespace/a. +/p +p + Generators for versions 1,3,4 and 5 UUIDapos;s are provided. The value held + in a UUID is represented by a specific hexadecimal format of the binary + fields. An example UUID string representation is: + F81D4FAE-7DEC-11D0-A765-00A0C91E6BF6. +/p +p + A cautionary note: there is no standard regarding binary representation of a + UUID other than its string format. /p /section section name=UUID version 4 p - The version 4 UUID is UUID based on random bytes. We fill the 128-bits with random bits (6 of the - bits are correspondingly set to flag the version and variant of the UUID). No special configuration - or implementation decisions are required to generate version 4 UUIDapos;s. + The version 4 UUID is UUID based on random bytes. We fill the 128-bits with + random bits (6 of the bits are correspondingly set to flag the version and + variant of the UUID). No special configuration or implementation decisions + are required to generate version 4 UUIDapos;s. /p /section section name=UUID version 3 p - Version 3 UUIDs are initialized using a name, a namespace, and the MD5 hashing algorithm. + Version 3 UUIDs are initialized using a name, a namespace, and the MD5 + hashing algorithm. /p /section section name=UUID version 5 - p - Version 5 UUIDs are initialized using a name, a namespace, and the SHA-1 hashing algorithm. +p + Version 5 UUIDs are initialized using a name, a namespace, and the SHA-1 + hashing algorithm. /p /section section name=UUID version 1 p - The version 1 UUID is a combination of node identifier (MAC address), timestamp and a random seed. - The version one generator uses the commons-discovery package to determine the implementation. - The implementations are specified by system properties. + The version 1 UUID is a combination of node identifier (MAC address), + timestamp and a random seed. The version one generator uses the + commons-discovery package to determine the implementation. The + implementations are specified by system properties. /p p table @@ -81,28 +93,33 @@ /p subsection name=Persistent State p - - The UUID draft specification calls for persisting generator state to stable non-volatile storage - (provisions are made for
svn commit: r280172 - /jakarta/commons/proper/commons-build/trunk/commons-site.jsl
Author: psteitz
Date: Sun Sep 11 12:57:49 2005
New Revision: 280172
URL: http://svn.apache.org/viewcvs?rev=280172view=rev
Log:
Added format definition for build.date.
Modified:
jakarta/commons/proper/commons-build/trunk/commons-site.jsl
Modified: jakarta/commons/proper/commons-build/trunk/commons-site.jsl
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/commons-build/trunk/commons-site.jsl?rev=280172r1=280171r2=280172view=diff
==
--- jakarta/commons/proper/commons-build/trunk/commons-site.jsl (original)
+++ jakarta/commons/proper/commons-build/trunk/commons-site.jsl Sun Sep 11
12:57:49 2005
@@ -34,6 +34,14 @@
!-- Stores location for publish date / version --
j:set var=date${maven.xdoc.date}/j:set
+
+!-- Format the build date depending the current locale if no pattern is
defined --
+j:if test=${currentLocale.equals(defaultLocale)}
+ j:if test=${now == null}
+j:useBean var=now class=java.util.Date/
+ /j:if
+ fmt:formatDate value=${now} type=date dateStyle=medium
var=build.date/
+/j:if
j:setProperties
object=${navbean}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons-build] Site build problem
There does not appear to be a reasonable way to make our customized site.jslwork with both pre- and post- 1.9 versions of the maven xdoc plugin. The best solution is to upgrade to 1.9+ before generating commons sites. I also just fixed a problem in commons-site.jsl that we preventing the date being displayed, so before generating commons sites, you should svn up commons-build. Phil
svn commit: r280174 - /jakarta/commons/sandbox/id/trunk/project.properties
Author: psteitz
Date: Sun Sep 11 13:09:31 2005
New Revision: 280174
URL: http://svn.apache.org/viewcvs?rev=280174view=rev
Log:
Eliminated properties mistakenly added.
Modified:
jakarta/commons/sandbox/id/trunk/project.properties
Modified: jakarta/commons/sandbox/id/trunk/project.properties
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/id/trunk/project.properties?rev=280174r1=280173r2=280174view=diff
==
--- jakarta/commons/sandbox/id/trunk/project.properties (original)
+++ jakarta/commons/sandbox/id/trunk/project.properties Sun Sep 11 13:09:31 2005
@@ -35,17 +35,11 @@
# commons site LF
##
maven.xdoc.jsl=../../trunks-proper/commons-build/commons-site.jsl
-maven.xdoc.date=bottom
+maven.xdoc.date=left
maven.xdoc.poweredby.image=maven-feather.png
maven.xdoc.version=${pom.currentVersion}
maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/commons/charter.html
maven.xdoc.includeProjectDocumentation=yes
-
-commons.project.extendsUri=../sandbox-build/
-
-maven.jar.override=on
-maven.clover.jar=/home/phil/committers/donated-licenses/clover/clover.jar
-maven.clover.license.path=/home/phil/committers/donated-licenses/clover/clover.license
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons-build] Site build problem
Hi Phil. Phil Steitz wrote: There does not appear to be a reasonable way to make our customized site.jslwork with both pre- and post- 1.9 versions of the maven xdoc plugin. The best solution is to upgrade to 1.9+ before generating commons sites. I also just fixed a problem in commons-site.jsl that we preventing the date being displayed, so before generating commons sites, you should svn up commons-build. That's a shame - I would have thought at least one of those solutions would have worked. Probably the most effective thing to do in this case is to put a check into commons-build/maven.xml to make sure the latest plugin is being used. That could be used to select the JSL to use (current or previous), but it might be better to recommend a consistent version (especially if some start requiring the i18n or other features, for example). Here's an example: http://svn.apache.org/viewcvs.cgi/maven/maven-1/plugins/trunk/faq/plugin.jelly?rev=267498view=markup Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons-build] Site build problem
On 9/11/05, Brett Porter [EMAIL PROTECTED] wrote: Hi Phil. Phil Steitz wrote: There does not appear to be a reasonable way to make our customized site.jslwork with both pre- and post- 1.9 versions of the maven xdoc plugin. The best solution is to upgrade to 1.9+ before generating commons sites. I also just fixed a problem in commons-site.jsl that we preventing the date being displayed, so before generating commons sites, you should svn up commons-build. That's a shame - I would have thought at least one of those solutions would have worked. The problem is that we have decoupled the site builds from commons-build - the individual projects reference commons-site.jsl directly. Probably the most effective thing to do in this case is to put a check into commons-build/maven.xml to make sure the latest plugin is being used. That could be used to select the JSL to use (current or previous), but it might be better to recommend a consistent version (especially if some start requiring the i18n or other features, for example). Given the current setup above, unless I am missing something, all of the maven.xml's would have to be modified to check, I guess this is possible. Is there any way to get commons-site.jsl to check? Thanks for your help on this and any ideas that you have on how to improve the setup. If you can see an any way to eliminate the dependency on the fmt library from commons-site.jsl without breaking site generation or to sneak it in somehow without breaking xdoc 1.9, that would also be great. Phil
RE: [Digester] Question about ports
On Sat, 2005-09-10 at 13:11 +1200, Simon Kitching wrote: [Aargh - I hate top-posting!] If someone wants to move Digester to Apache XML, I wouldn't object. However I don't feel particularly motivated to do it myself. xml is now a federation of top level projects. IMHO digester isn't big enough to be a TLP. I think the easiest way to deal with this particular case (python/ruby versions of Digester) is for the ports to be separate projects at sourceforge/rubyforge/etc. I'm happy to have links to those projects from the Digester homepage and the Wiki. +1 feel free to post stuff to this list (announcements and so on or questions) if you want... Running these projects as real Apache projects means that committers must be Apache committers, which means project members (like Silas) need to go through a fairly lengthy trial phase with an existing Apache committer (or several) willing to evaluate patches etc. before being proposed as official Apache committers. I don't know if any existing Digester committers are python people - I'm certainly not. So it just looks easier to run this stuff as an external project. Anyway, it's not really the same project; it's just a project in a different language that happens to share the same basic architectural concepts. +1 apache is changing quite a lot at the moment and a lot of process stuff is still being developed and documented. there's quite a danger of losing momentum if you become entangled with the process ATM. IMHO better to start coding now: there's always the possibility of moving to apache later. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r280180 - in /jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/xmlrules: test-node-create-rules-input.xml test-node-create-rules.xml
Author: rdonkin Date: Sun Sep 11 13:48:20 2005 New Revision: 280180 URL: http://svn.apache.org/viewcvs?rev=280180view=rev Log: Added some files I'd missed :( Added: jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/xmlrules/test-node-create-rules-input.xml jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/xmlrules/test-node-create-rules.xml Added: jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/xmlrules/test-node-create-rules-input.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/xmlrules/test-node-create-rules-input.xml?rev=280180view=auto == --- jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/xmlrules/test-node-create-rules-input.xml (added) +++ jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/xmlrules/test-node-create-rules-input.xml Sun Sep 11 13:48:20 2005 @@ -0,0 +1,22 @@ +?xml version=1.0? +!-- Input data to test the DigesterLoader -- +!-- + Copyright 2001-2004 The Apache Software Foundation. + + Licensed under the Apache License, Version 2.0 (the License); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an AS IS BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +-- +root + foo1 + bar1bar1-value/bar1 + /foo1 +/root Added: jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/xmlrules/test-node-create-rules.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/xmlrules/test-node-create-rules.xml?rev=280180view=auto == --- jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/xmlrules/test-node-create-rules.xml (added) +++ jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/xmlrules/test-node-create-rules.xml Sun Sep 11 13:48:20 2005 @@ -0,0 +1,24 @@ +?xml version=1.0? +!-- + Copyright 2001-2004 The Apache Software Foundation. + + Licensed under the Apache License, Version 2.0 (the License); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an AS IS BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. + +!DOCTYPE digester-rules PUBLIC -//Jakarta Apache //DTD digester-rules XML V1.0//EN http://jakarta.apache.org/commons/digester/dtds/digester-rules.dtd; +-- +digester-rules + pattern value=root/foo1 + node-create-rule/ + set-next-rule methodname=add paramtype=java.lang.Object/ + /pattern +/digester-rules - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r280181 - /jakarta/commons/proper/digester/trunk/build.xml
Author: rdonkin
Date: Sun Sep 11 13:54:48 2005
New Revision: 280181
URL: http://svn.apache.org/viewcvs?rev=280181view=rev
Log:
Added notice file to jar.
Modified:
jakarta/commons/proper/digester/trunk/build.xml
Modified: jakarta/commons/proper/digester/trunk/build.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/trunk/build.xml?rev=280181r1=280180r2=280181view=diff
==
--- jakarta/commons/proper/digester/trunk/build.xml (original)
+++ jakarta/commons/proper/digester/trunk/build.xml Sun Sep 11 13:54:48 2005
@@ -186,6 +186,8 @@
/copy
copy file=LICENSE.txt
todir=${build.home}/classes/META-INF/
+copy file=NOTICE.txt
+ todir=${build.home}/classes/META-INF/
/target
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Bug report for Commons [2005/09/11]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 6508|Ass|Enh|2002-02-17|[lakta] HttpClient now supports proxyHost and prox| | 6826|Ass|Enh|2002-03-04|[lakta] Need to have xml files validated against D| | 6829|Ass|Enh|2002-03-04|[lakta] Allow easier way of user specified tests | | 7069|Ass|Enh|2002-03-13|[lakta] DTD and DOM Validators| | 7135|Opn|Enh|2002-03-14|[beanutils] Misleading error message when beaninfo| | 7226|Opn|Enh|2002-03-19|[beanutils] Nested Bean Collection| | 7367|New|Nor|2002-03-22|[services] ServiceManager not actually serializabl| | 7465|New|Nor|2002-03-25|[lakta] Need better 'dist' build | | 7981|Ver|Nor|2002-04-11|[codec][PATCH] add 2 new methods for encoding stri| |10319|New|Enh|2002-06-28|[beanutils] Instantiate property if null in form b| |12807|New|Nor|2002-09-19|[lakta][PATCH] Update build.xml to use commons-log| |13390|New|Nor|2002-10-07|[lakta] ResponseHeaderHandler and ResponseHeaderVa| |13426|New|Enh|2002-10-08|[lakta][PATCH] xml-reference.xml responseHeader ad| |13743|Opn|Enh|2002-10-17|[beanutils] Need getPropertyType(Class theClass, S| |14394|Ver|Nor|2002-11-08|[beanutils] Excessive exceptions log under securit| |14471|Inf|Enh|2002-11-12|[validator] validator-rules.xml JavaScript fails w| |14667|Ver|Maj|2002-11-19|[beanutils] PropertyUtils.copyProperties does not | |15451|Opn|Enh|2002-12-17|[beanutils] Multiple mapped properties not possibl| |15519|Ver|Maj|2002-12-19|[beanutils] PropertyUtils.getPropertyType() for ja| |15744|New|Nor|2002-12-31|[scaffold] Scaffold ResultSet used after statement| |16038|Opn|Enh|2003-01-13|[beanutils] LocaleBeanUtils.copyProperties() does | |16394|New|Enh|2003-01-24|[validator] Enhance the IndexedListProperty to han| |16525|Opn|Enh|2003-01-29|[beanutils] BeanUtils.setProperty is over-zealous | |16600|New|Nor|2003-01-30|[lakta] JUnitTestAdapter throws SAXException becau| |16634|New|Enh|2003-01-31|[validator] Change ValidatorUtils.getValueAsString| |16873|New|Enh|2003-02-07|[lakta] Specifying a different latka.properties fi| |17002|New|Enh|2003-02-12|[beanutils] Problem with index property | |17102|New|Enh|2003-02-15|[lakta] Can't embed characters in paramValue | |17306|Opn|Enh|2003-02-22|[validator] Extend field tag with forward attr| |17501|New|Enh|2003-02-27|[beanutils] Add dynamic discovery of mapped proper| |17662|New|Nor|2003-03-05|[cli] Unknown options are ignored instead of throw| |17663|New|Nor|2003-03-05|[beanutils] getArrayProperty does not use ConvertU| |17682|New|Nor|2003-03-05|[cli] HelpFormatter does not wrap lines correctly | |17769|New|Blk|2003-03-07|[scaffold] pre-mature closing of Statement and Pre| |17957|New|Cri|2003-03-13|[launcher] - on OutOfMemoryError no message | |18087|New|Enh|2003-03-18|[beanutils] Add BeanFactory class for dynamic fact| |18773|New|Enh|2003-04-07|[reflect] Can add a method cache in MethodUtils | |18811|New|Min|2003-04-08|[beanutils] Misleading error message in Converting| |18942|New|Enh|2003-04-11|[beanutils] Add t/f to BooleanConverter | |19781|New|Nor|2003-05-08|[beanutils] PropertyUtils.copyProperties throws ex| |19857|New|Enh|2003-05-12|[beanutils] Methods ConvertUtilsBean.convert could| |20015|Ass|Nor|2003-05-18|[lang] Make Entities public and unit test | |20027|New|Enh|2003-05-19|[beanutils] ConvertUtils enhancements | |20057|New|Nor|2003-05-20|[lakta] Difficulty to download sample Latka test| |20067|New|Nor|2003-05-20|[lakta] sample Latka test suite SUITE FAILED - c| |20449|New|Enh|2003-06-03|[validator] Define flag for validating current pag| |20520|New|Enh|2003-06-05|[beanutils] MethodUtils: Need easy way to invoke s| |20523|New|Enh|2003-06-05|[fileupload] Model FileUpload model to mimic javax| |20549|New|Enh|2003-06-06|[beanutils] Handling of exceptions thrown during B| |20686|New|Enh|2003-06-11|[beanutils] Register converters by both target cla| |20836|New|Enh|2003-06-17|[beanutils] Localizing beanutils |
svn commit: r280182 - /jakarta/commons/proper/digester/trunk/src/conf/MANIFEST.MF
Author: rdonkin Date: Sun Sep 11 14:09:56 2005 New Revision: 280182 URL: http://svn.apache.org/viewcvs?rev=280182view=rev Log: Changed implementation version in the manefest in preparation for snapshot. Modified: jakarta/commons/proper/digester/trunk/src/conf/MANIFEST.MF Modified: jakarta/commons/proper/digester/trunk/src/conf/MANIFEST.MF URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/trunk/src/conf/MANIFEST.MF?rev=280182r1=280181r2=280182view=diff == --- jakarta/commons/proper/digester/trunk/src/conf/MANIFEST.MF (original) +++ jakarta/commons/proper/digester/trunk/src/conf/MANIFEST.MF Sun Sep 11 14:09:56 2005 @@ -4,5 +4,4 @@ Specification-Version: 1.7 Implementation-Title: org.apache.commons.digester Implementation-Vendor: The Apache Software Foundation -Implementation-Version: 1.7 - +Implementation-Version: 20050911 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Digester] Question about ports
Just make sure you use the apache license! I think the idea/concept of Digester is big enough to merit a TLP (or group of them). And, since it's an XML-specific technology, I think it belongs within the XML group. Then again, I'm no expert here, but it seems an obvious fit to me. -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Sunday, September 11, 2005 4:46 PM To: Jakarta Commons Developers List Subject: RE: [Digester] Question about ports On Sat, 2005-09-10 at 13:11 +1200, Simon Kitching wrote: [Aargh - I hate top-posting!] If someone wants to move Digester to Apache XML, I wouldn't object. However I don't feel particularly motivated to do it myself. xml is now a federation of top level projects. IMHO digester isn't big enough to be a TLP. I think the easiest way to deal with this particular case (python/ruby versions of Digester) is for the ports to be separate projects at sourceforge/rubyforge/etc. I'm happy to have links to those projects from the Digester homepage and the Wiki. +1 feel free to post stuff to this list (announcements and so on or questions) if you want... Running these projects as real Apache projects means that committers must be Apache committers, which means project members (like Silas) need to go through a fairly lengthy trial phase with an existing Apache committer (or several) willing to evaluate patches etc. before being proposed as official Apache committers. I don't know if any existing Digester committers are python people - I'm certainly not. So it just looks easier to run this stuff as an external project. Anyway, it's not really the same project; it's just a project in a different language that happens to share the same basic architectural concepts. +1 apache is changing quite a lot at the moment and a lot of process stuff is still being developed and documented. there's quite a danger of losing momentum if you become entangled with the process ATM. IMHO better to start coding now: there's always the possibility of moving to apache later. - robert - 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]
svn commit: r280183 - /jakarta/commons/proper/digester/tags/SNAPSHOT_20050911/
Author: rdonkin Date: Sun Sep 11 14:23:25 2005 New Revision: 280183 URL: http://svn.apache.org/viewcvs?rev=280183view=rev Log: Tag for snapshot. Added: jakarta/commons/proper/digester/tags/SNAPSHOT_20050911/ - copied from r280182, jakarta/commons/proper/digester/trunk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Digester] Question about ports
On Sun, 2005-09-11 at 17:11 -0400, James Carman wrote: Just make sure you use the apache license! +1 use version 2 :) I think the idea/concept of Digester is big enough to merit a TLP (or group of them). And, since it's an XML-specific technology, I think it belongs within the XML group. Then again, I'm no expert here, but it seems an obvious fit to me. IMHO too many small TLPs would bring difficulties. for example, i'm not sure whether it would make sense to have an ASF board member for digester. what has been in the air (and in my mind) for a little while is the idea of a TLP bring together various code-centric mapping and binding technologies from both inside and outside apache but IMHO the time isn't right (as yet). - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons-build] Site build problem
Phil Steitz wrote: Given the current setup above, unless I am missing something, all of the maven.xml's would have to be modified to check, I guess this is possible. Fair enough - I thought all the projects extended commons-build/project.xml (and hence used it's maven.xml). Is there any way to get commons-site.jsl to check? Unfortunately not - fmt is required to parse the file so it will still die before that. Thanks for your help on this and any ideas that you have on how to improve the setup. I've fiddled with a few things, but haven't had much luck: - tried to revert to the non fmt: version from 1.8 but it seems there are 2 incompatibilities in 1.9: the removal of build.date and the requirement of messages / to be processed to handle the generated content. It would have been good for i18n to be an option that was enabled and the old stuff retained otherwise. - tried to do the failing as above, and tried to select the old or new jsl inside the jsl based on the plugin version, but neither worked The one option I'd consider is whether it is worth ditching commons-site.jsl altogether. I have no idea what it is meant to add: setting maven.xdoc.theme=classic looks the same to me (except for the addition of the the external link icons which can be removed through CSS). If you'd like me to commit that for commons-math I can. Does anyone know what it was meant to do, other than insulate against changes in the Maven generated site? I know that doesn't solve the fundamental problem in the plugin, but might be the best solution for commons. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [File Upload] New release planned?
My understanding is that a commons-fileupload version 1.1 is waiting on a release of commons-io, which seems imminent: http://www.mail-archive.com/commons-dev%40jakarta.apache.org/msg67118.html Niall - Original Message - From: Howard Lewis Ship [EMAIL PROTECTED] To: commons-dev@jakarta.apache.org Sent: Saturday, September 10, 2005 2:38 PM Subject: Fwd: [File Upload] New release planned? I'd like to add upload file support to Tapestry Portlet, but we currently use fileupload 1.0, which doesn't support it. I noticed that the code is in place to support portlets. Is there a release planned? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Complex equals
Phil Steitz wrote: Yes, you are correct about the IEEE 745 spec, but one could argue that the spec applies only to primitive values - at least that seems to be the way it works in Java. Since equals among objects in Java *must* be reflexive, Ok, this makes sense. Before the change, 0 + NaN * i was not equal to NaN + i for example, It can be argued this is correct behaviour, while: wheras isNaN returns true for both. this may be misleading (although still correct). J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Digester] Question about ports
I wasn't aware that (again, I'm somewhat of a newbie) there had to be a board member for each TLP within Apache. Of course, I didn't realize that all projects within Apache XML are TLPs. If XML itself were a TLP with each project within it merely being a subproject (a la Jakarta), then I would say that Digester (or DigesterJ) should be a subproject of it. But, if it's structured as you say it is, then maybe you're right. The way I would see the hierarchy would be: Apache - XML - Digester - different flavors (perl, ruby, Java, python, etc.). So, Digester (as a concept; like logging) would be a subproject within XML (not a TLP), since it's XML-specific. -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Sunday, September 11, 2005 5:51 PM To: Jakarta Commons Developers List Subject: RE: [Digester] Question about ports On Sun, 2005-09-11 at 17:11 -0400, James Carman wrote: Just make sure you use the apache license! +1 use version 2 :) I think the idea/concept of Digester is big enough to merit a TLP (or group of them). And, since it's an XML-specific technology, I think it belongs within the XML group. Then again, I'm no expert here, but it seems an obvious fit to me. IMHO too many small TLPs would bring difficulties. for example, i'm not sure whether it would make sense to have an ASF board member for digester. what has been in the air (and in my mind) for a little while is the idea of a TLP bring together various code-centric mapping and binding technologies from both inside and outside apache but IMHO the time isn't right (as yet). - robert - 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: [math] Complex equals
On 9/11/05, J.Pietschmann [EMAIL PROTECTED] wrote: Phil Steitz wrote: Yes, you are correct about the IEEE 745 spec, but one could argue that the spec applies only to primitive values - at least that seems to be the way it works in Java. Since equals among objects in Java *must* be reflexive, Ok, this makes sense. Before the change, 0 + NaN * i was not equal to NaN + i for example, It can be argued this is correct behaviour, while: wheras isNaN returns true for both. this may be misleading (although still correct). J.Pietschmann So which do you prefer? I don't think we can change the isNaN behavior. It seems more natural to me in any case for NaN in either part to make the complex number NaN and, as I said above, this is also consistent with what the operations do - most have an isNaN check at the beginning and return Complex.NaN if an operand isNaN. It seems more natural to me at least to view all values with either part NaN to be the same and equal to Complex.NaN. By definition, complex numbers have real numbers as their real and imaginary parts. When one of these is NaN, the result is not a complex number. Note this is not the same as when one of the values is infinite. Going through the (old) archives, I remember at one point we were talking about adhering to C9x Annex G: IEC 559-compatible complex arithmetic*. *I can't put my hands on that spec right now, but I will have a look to see what the recommendation is. It looks like Colt / VNI identifies NaN values as I am proposing, but there is a note in the javadoc saying this is contrary to the Annex G spec. i will look into this. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons-build] Site build problem
From: Brett Porter [EMAIL PROTECTED] Phil Steitz wrote: Given the current setup above, unless I am missing something, all of the maven.xml's would have to be modified to check, I guess this is possible. Fair enough - I thought all the projects extended commons-build/project.xml (and hence used it's maven.xml). I did a quick scan and only attributes and chain extend the commons-build/project.xml - but maybe all commons components should? If they did - isn't the simplest solution to add a plugin dependency to commons-build/project.xml? dependency groupIdmaven/groupId artifactIdmaven-xdoc-plugin/artifactId version1.9.2/version urlhttp://maven.apache.org/reference/plugins/xdoc/url typeplugin/type /dependency I tried this with validator and it worked fine, downloading the 1.9.2 xdoc version and running. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons-build] Site build problem
On 9/11/05, Niall Pemberton [EMAIL PROTECTED] wrote: From: Brett Porter [EMAIL PROTECTED] Phil Steitz wrote: Given the current setup above, unless I am missing something, all of the maven.xml's would have to be modified to check, I guess this is possible. Fair enough - I thought all the projects extended commons-build/project.xml (and hence used it's maven.xml). I did a quick scan and only attributes and chain extend the commons-build/project.xml - but maybe all commons components should? That used to be the setup, and lots of people complained, since it meant that even to just build/jar the components, you had to have commons-build checked out, among other things. Of course, the web sites now depend on the commons-site.jsl, style sheets and nav elements, so you effectively have to have it checked out to do site gens, so it is worth considering going back to extending. If they did - isn't the simplest solution to add a plugin dependency commons-build/project.xml? dependency groupIdmaven/groupId artifactIdmaven-xdoc-plugin/artifactId version1.9.2/version urlhttp://maven.apache.org/reference/plugins/xdoc/url typeplugin/type /dependency I tried this with validator and it worked fine, downloading the 1.9.2 xdoc version and running. Niall Yes, that would work for the current problem, but I am not sure all would be happy about going back to all extending the commons-build POM. Thoughts? Phil
Re: [commons-build] Site build problem
- Original Message - From: Phil Steitz [EMAIL PROTECTED] On 9/11/05, Niall Pemberton [EMAIL PROTECTED] wrote: I did a quick scan and only attributes and chain extend the commons-build/project.xml - but maybe all commons components should? That used to be the setup, and lots of people complained, since it meant that even to just build/jar the components, you had to have commons-build checked out, among other things. Of course, the web sites now depend on the commons-site.jsl, style sheets and nav elements, so you effectively have to have it checked out to do site gens, so it is worth considering going back to extending. OK, my suggestion: 1) Add a dependency for the 1.9.2 maven-xdoc-plugin to the commons-build's project.xml 2) Add a commons-site-xdoc-1.8.jsl to commons-build that reflects commons-site.jsl before you made your change - i.e. doesn't require the 1.9.2 maven-xdoc-plugin. 3) Post an [all] message to this list that explains the issue and telling projects they have a choice of three solutions a) extends commons-build/project.xml or b) add a plugin dependency to their project.xml or c) change their project.properties to point to commons-site-xdoc-1.8.jsl. Then its down to individual projects which way they want to jump. Niall P.S. Put notes in the two jsl files explaining the difference between the two. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons-build] Site build problem
On 9/11/05, Phil Steitz [EMAIL PROTECTED] wrote: On 9/11/05, Niall Pemberton [EMAIL PROTECTED] wrote: From: Brett Porter [EMAIL PROTECTED] Phil Steitz wrote: Given the current setup above, unless I am missing something, all of the maven.xml's would have to be modified to check, I guess this is possible. Fair enough - I thought all the projects extended commons-build/project.xml (and hence used it's maven.xml). I did a quick scan and only attributes and chain extend the commons-build/project.xml - but maybe all commons components should? That used to be the setup, and lots of people complained, since it meant that even to just build/jar the components, you had to have commons-build checked out, among other things. Of course, the web sites now depend on the commons-site.jsl, style sheets and nav elements, so you effectively have to have it checked out to do site gens, so it is worth considering going back to extending. We have Subversion now, and so svn:externals, which gives us an alternative to having to check out commons-build separately... -- Martin Cooper If they did - isn't the simplest solution to add a plugin dependency commons-build/project.xml? dependency groupIdmaven/groupId artifactIdmaven-xdoc-plugin/artifactId version1.9.2/version urlhttp://maven.apache.org/reference/plugins/xdoc/url typeplugin/type /dependency I tried this with validator and it worked fine, downloading the 1.9.2xdoc version and running. Niall Yes, that would work for the current problem, but I am not sure all would be happy about going back to all extending the commons-build POM. Thoughts? Phil
svn commit: r280233 - /jakarta/commons/proper/commons-build/trunk/project.properties
Author: niallp Date: Sun Sep 11 18:27:43 2005 New Revision: 280233 URL: http://svn.apache.org/viewcvs?rev=280233view=rev Log: Correct includeProjectDocumentation from false to no. Modified: jakarta/commons/proper/commons-build/trunk/project.properties Modified: jakarta/commons/proper/commons-build/trunk/project.properties URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/commons-build/trunk/project.properties?rev=280233r1=280232r2=280233view=diff == --- jakarta/commons/proper/commons-build/trunk/project.properties (original) +++ jakarta/commons/proper/commons-build/trunk/project.properties Sun Sep 11 18:27:43 2005 @@ -49,7 +49,7 @@ maven.xdoc.date=left maven.xdoc.poweredby.image=maven-feather.png maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/commons/charter.html -maven.xdoc.includeProjectDocumentation=false +maven.xdoc.includeProjectDocumentation=no # once we create a theme url it should go here. #maven.xdoc.theme.url= - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36602] New: - [attributes] Project Documentation section missing from website navigation bar
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=36602. 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=36602 Summary: [attributes] Project Documentation section missing from website navigation bar Product: Commons Version: Nightly Builds Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: attributes AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] The project documentation section is missing from the navigation bar on the web site. This is because attributes project.xml inherits from commons-build/project.xml which causes the commons-build/project.properties to be inherited and the commons-build/project.properties has the maven.xdoc.includeProjectDocumentation set to no. In order to have the Project Documentation included in the navigation bar then this property just needs to be overriden to yes. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36602] - [attributes] Project Documentation section missing from website navigation bar
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=36602. 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=36602 --- Additional Comments From [EMAIL PROTECTED] 2005-09-12 03:34 --- Created an attachment (id=16363) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16363action=view) project.properties patch -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36603] New: - [chain] Project Documentation section missing from website navigation bar
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=36603. 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=36603 Summary: [chain] Project Documentation section missing from website navigation bar Product: Commons Version: Nightly Builds Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: chain AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] The project documentation section is missing from the navigation bar on the web site. This is because attributes project.xml inherits from commons-build/project.xml which causes the commons-build/project.properties to be inherited and the commons-build/project.properties has the maven.xdoc.includeProjectDocumentation set to no. In order to have the Project Documentation included in the navigation bar then this property just needs to be overriden to yes. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36603] - [chain] Project Documentation section missing from website navigation bar
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=36603. 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=36603 --- Additional Comments From [EMAIL PROTECTED] 2005-09-12 03:35 --- Created an attachment (id=16364) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16364action=view) project.properties patch -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons-build] Site build problem
We have Subversion now, and so svn:externals, which gives us an alternative to having to check out commons-build separately... This still has 2 problems: - you end up with X checkouts of commons-build where X is the number of projects in commons you have checked out - You also have to do a copy of this directory at release time (this is probably preferable to now where you always get the current version, even for an old tag), you can't rely on the versioning of the external. I think this option I raised earlier got missed, so I'll repeat here: The one option I'd consider is whether it is worth ditching commons-site.jsl altogether. I have no idea what it adds: setting maven.xdoc.theme=classic instead looks the same to me (except for the addition of the the external link icons which can be removed through CSS). If you'd like me to commit that for commons-math I can. Does anyone know what it was meant to do, other than insulate against changes in the Maven generated site? I know that doesn't solve the fundamental problem in the plugin, but might be the best solution for commons. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons-build] Site build problem
- Original Message - From: Brett Porter [EMAIL PROTECTED] Sent: Monday, September 12, 2005 2:36 AM I think this option I raised earlier got missed, so I'll repeat here: The one option I'd consider is whether it is worth ditching commons-site.jsl altogether. I have no idea what it adds: setting maven.xdoc.theme=classic instead looks the same to me (except for the addition of the the external link icons which can be removed through CSS). If you'd like me to commit that for commons-math I can. Does anyone know what it was meant to do, other than insulate against changes in the Maven generated site? One thing it does is add the standard commons About Us menu before the project menu. I know that doesn't solve the fundamental problem in the plugin, but might be the best solution for commons. IMO we would still need have a dependency on a specific xdoc plugin version - otherwise what different components' sites look like could vary depending on what version plugin happened to be installed. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36584] - [lang] adding a StringUtils.replace method that takes an array or List of replacement strings
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=36584. 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=36584 --- Additional Comments From [EMAIL PROTECTED] 2005-09-12 06:38 --- First off, I am interested in this since StringUtils.replace is used heavily in my app, and if I loop through and call that in cases where multiple replaces are needed, then tons of Strings are created and collected. I think there should be a method in StringUtils for this. As to if StrBuilder could do a good job with this is a good question. I have a feeling that keeping the same algorithm I use will not be possible with StrBuilder, though I am not sure. If the method is in StringUtils does that mean it shouldnt use StrBuilder since that is a different package? If not, let me know and I can research further. I wrote a method to do this, and focused on performance (so it is a bit long winded). If you think it is ok, lets add it to StringUtils. If you have comments or questions let me know and I can research and recode. I will add an attachment of the code and test cases. Thanks! Chris -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36584] - [lang] adding a StringUtils.replace method that takes an array or List of replacement strings
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=36584. 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=36584 --- Additional Comments From [EMAIL PROTECTED] 2005-09-12 06:42 --- Created an attachment (id=16365) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16365action=view) Some methods for StringUtils, and some for StringUtilsTest -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [commons-build] Site build problem
I opened a new bug for this incompatibility issue. http://jira.codehaus.org/browse/MPXDOC-167 Arnaud -Message d'origine- De : Niall Pemberton [mailto:[EMAIL PROTECTED] Envoyé : lundi 12 septembre 2005 06:14 À : Jakarta Commons Developers List Objet : Re: [commons-build] Site build problem - Original Message - From: Brett Porter [EMAIL PROTECTED] Sent: Monday, September 12, 2005 2:36 AM I think this option I raised earlier got missed, so I'll repeat here: The one option I'd consider is whether it is worth ditching commons-site.jsl altogether. I have no idea what it adds: setting maven.xdoc.theme=classic instead looks the same to me (except for the addition of the the external link icons which can be removed through CSS). If you'd like me to commit that for commons-math I can. Does anyone know what it was meant to do, other than insulate against changes in the Maven generated site? One thing it does is add the standard commons About Us menu before the project menu. I know that doesn't solve the fundamental problem in the plugin, but might be the best solution for commons. IMO we would still need have a dependency on a specific xdoc plugin version - otherwise what different components' sites look like could vary depending on what version plugin happened to be installed. Niall - 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]
