svn commit: r551000 - in /jakarta/commons/proper/fileupload/trunk: ./ src/changes/ src/java/org/apache/commons/fileupload/ src/test/org/apache/commons/fileupload/
Author: jochen
Date: Tue Jun 26 17:59:16 2007
New Revision: 551000
URL: http://svn.apache.org/viewvc?view=rev&rev=551000
Log:
Short files could cause an unexpected end of the item stream.
PR: FILEUPLOAD-135
Submitted-By: Alexander Sova <[EMAIL PROTECTED]>
Modified:
jakarta/commons/proper/fileupload/trunk/pom.xml
jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadException.java
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java
jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/MockHttpServletRequest.java
jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/StreamingTest.java
Modified: jakarta/commons/proper/fileupload/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/pom.xml?view=diff&rev=551000&r1=550999&r2=551000
==
--- jakarta/commons/proper/fileupload/trunk/pom.xml (original)
+++ jakarta/commons/proper/fileupload/trunk/pom.xml Tue Jun 26 17:59:16 2007
@@ -105,6 +105,10 @@
[EMAIL PROTECTED]
+ Alexander Sova
+ [EMAIL PROTECTED]
+
+
Thomas Vandahl
[EMAIL PROTECTED]
Modified: jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml?view=diff&rev=551000&r1=550999&r2=551000
==
--- jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml (original)
+++ jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml Tue Jun 26
17:59:16 2007
@@ -64,56 +64,50 @@
due-to="Thomas Vandahl" due-to-email="[EMAIL PROTECTED]">
DiskFileItem.toString() could throw an NPE.
+
+Short files could cause an unexpected end of the item stream.
+
-
Made Streams.asString static.
-
Eliminated duplicate code.
-
Added a streaming API.
-
Eliminated the necessity of a content-length header.
-
Eliminated the limitation of a maximum size for a single
header line. (The total size of all headers is already
limited, so there's no need for another limit.)
-
Added the ProgressListener, which allows to implement a
progress bar.
-
Added support for header continuation lines.
-
It is now possible to limit the actual file size and not
the request size.
-
Added the FileCleanerCleanup as an example for how to close
down the FileCleaner's reaper thread nicely.
-
A descriptive NPE is now thrown, if the FileItemFactory
has not been set.
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadException.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadException.java?view=diff&rev=551000&r1=550999&r2=551000
======
---
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadException.java
(original)
+++
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadException.java
Tue Jun 26 17:59:16 2007
@@ -92,4 +92,8 @@
cause.printStackTrace(writer);
}
}
+
+public Throwable getCause() {
+return cause;
+ }
}
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java?view=diff&rev=551000&r1=550999&r2=551000
==========
---
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java
(original)
+++
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java
Tue Jun 26 17:59:16 2007
@@ -21,6 +21,7 @@
import java.io.InputStream;
import java.io.OutputStream;
import java.io.UnsupportedEncodingException;
+import java.util.Arrays;
import org.apache.commons.fileupload.util.Closeable;
import org.apache.commons.fileupload.util.Streams;
@@ -202,13 +203,6 @@
CR, LF, DASH, DASH};
-/**
- * The number of bytes, over and above the boundary size, to
svn commit: r545004 - in /jakarta/commons/proper/fileupload/trunk: pom.xml src/changes/changes.xml src/java/org/apache/commons/fileupload/disk/DiskFileItem.java
Author: jochen
Date: Wed Jun 6 17:05:29 2007
New Revision: 545004
URL: http://svn.apache.org/viewvc?view=rev&rev=545004
Log:
DiskFileItem.toString() could throw an NPE.
PR: FILEUPLOAD-134
Submitted-by: Thomas Vandahl, [EMAIL PROTECTED]
Modified:
jakarta/commons/proper/fileupload/trunk/pom.xml
jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java
Modified: jakarta/commons/proper/fileupload/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/pom.xml?view=diff&rev=545004&r1=545003&r2=545004
==
--- jakarta/commons/proper/fileupload/trunk/pom.xml (original)
+++ jakarta/commons/proper/fileupload/trunk/pom.xml Wed Jun 6 17:05:29 2007
@@ -97,16 +97,20 @@
[EMAIL PROTECTED]
+ Michael Macaluso
+ [EMAIL PROTECTED]
+
+
Amichai Rothman
[EMAIL PROTECTED]
- Henry Yandell
- [EMAIL PROTECTED]
+ Thomas Vandahl
+ [EMAIL PROTECTED]
- Michael Macaluso
- [EMAIL PROTECTED]
+ Henry Yandell
+ [EMAIL PROTECTED]
Modified: jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml?view=diff&rev=545004&r1=545003&r2=545004
==
--- jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml (original)
+++ jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml Wed Jun 6
17:05:29 2007
@@ -60,6 +60,10 @@
A MalformedStreamException is now thrown, if the size of an items
headers exceeds HEADER_PART_SIZE_MAX;
+
+DiskFileItem.toString() could throw an NPE.
+
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java?view=diff&rev=545004&r1=545003&r2=545004
==
---
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java
(original)
+++
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java
Wed Jun 6 17:05:29 2007
@@ -629,7 +629,7 @@
* memory.
*/
public File getStoreLocation() {
-return dfos.getFile();
+return dfos == null ? null : dfos.getFile();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r544995 - in /jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk: DiskFileItem.java DiskFileItemFactory.java
Author: jochen
Date: Wed Jun 6 16:51:28 2007
New Revision: 544995
URL: http://svn.apache.org/viewvc?view=rev&rev=544995
Log:
Documented that the FileCleaningTracker may be null
to disable tracking.
PR: FILEUPLOAD-133
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItemFactory.java
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java?view=diff&rev=544995&r1=544994&r2=544995
==
---
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java
(original)
+++
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java
Wed Jun 6 16:51:28 2007
@@ -216,7 +216,8 @@
* Constructs a new DiskFileItem instance.
*
* @param tracker The tracker, which is responsible for deleting
- * the temporary file.
+ * the temporary file. May be null, if the file
+ * doesn't need to be tracked.
* @param fieldName The name of the form field.
* @param contentType The content type passed by the browser or
* null if not specified.
@@ -648,10 +649,11 @@
/**
- * Creates and returns a [EMAIL PROTECTED] java.io.File File} representing
a uniquely
- * named temporary file in the configured repository path. The lifetime of
- * the file is tied to the lifetime of the FileItem instance;
- * the file will be deleted when the instance is garbage collected.
+ * Creates and returns a [EMAIL PROTECTED] java.io.File File}
representing a uniquely
+ * named temporary file in the configured repository path.
+ * If the file item factory has an associated [EMAIL PROTECTED]
FileCleaningTracker},
+ * then the lifetime of the file is tied to the lifetime of the
FileItem
+ * instance: The file will be deleted when the instance is garbage
collected.
*
* @return The [EMAIL PROTECTED] java.io.File File} to be used for
temporary storage.
*/
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItemFactory.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItemFactory.java?view=diff&rev=544995&r1=544994&r2=544995
==
---
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItemFactory.java
(original)
+++
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItemFactory.java
Wed Jun 6 16:51:28 2007
@@ -85,8 +85,9 @@
/**
- * The instance of [EMAIL PROTECTED] FileCleaningTracker}, which is
responsible
- * for deleting temporary files.
+ * The instance of [EMAIL PROTECTED] FileCleaningTracker}, which is
responsible
+ * for deleting temporary files.
+ * May be null, if tracking files is not required.
*/
private FileCleaningTracker fileCleaningTracker;
@@ -130,7 +131,8 @@
* which files will be created, should the item size
* exceed the threshold.
* @param tracker The tracker, which is responsible to delete
- * temporary files.
+ * temporary files. May be null, if files don't need
+ * to be tracked.
*/
public DiskFileItemFactory(FileCleaningTracker tracker, int sizeThreshold,
File repository) {
@@ -226,7 +228,8 @@
* Returns the tracker, which is responsible for deleting temporary
* files.
* @return An instance of [EMAIL PROTECTED] FileCleaningTracker}, defaults
to
- * [EMAIL PROTECTED] FileCleaner#getInstance()}.
+ * [EMAIL PROTECTED] FileCleaner#getInstance()}. Null, if temporary files
+ * aren't tracked.
*/
public FileCleaningTracker getFileCleaningTracker() {
return fileCleaningTracker;
@@ -236,7 +239,8 @@
* Returns the tracker, which is responsible for deleting temporary
* files.
* @param pTracker An instance of [EMAIL PROTECTED] FileCleaningTracker},
- * which will from now on track the created files.
+ * which will from now on track the created files. May be null
+ * to disable tracking.
*/
public void setFileCleaningTracker(FileCleaningTracker pTracker
svn commit: r526346 - in /jakarta/commons/proper/fileupload/trunk/src: changes/changes.xml java/org/apache/commons/fileupload/MultipartStream.java
Author: jochen
Date: Fri Apr 6 19:04:55 2007
New Revision: 526346
URL: http://svn.apache.org/viewvc?view=rev&rev=526346
Log:
A MalformedStreamException is now thrown, if the size of an
items headers exceeds HEADER_PART_SIZE_MAX.
PR: FILEUPLOAD-116
Submitted-by: Amichai Rothman <[EMAIL PROTECTED]>
Modified:
jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java
Modified: jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml?view=diff&rev=526346&r1=526345&r2=526346
==
--- jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml (original)
+++ jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml Fri Apr 6
19:04:55 2007
@@ -55,6 +55,11 @@
due-to="Michael Macaluso" due-to-email="[EMAIL PROTECTED]">
Added support for accessing the file item headers.
+
+A MalformedStreamException is now thrown, if the size of an items
+headers exceeds HEADER_PART_SIZE_MAX;
+
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java?view=diff&rev=526346&r1=526345&r2=526346
==
---
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java
(original)
+++
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java
Fri Apr 6 19:04:55 2007
@@ -530,26 +530,27 @@
public String readHeaders()
throws MalformedStreamException {
int i = 0;
-byte[] b = new byte[1];
+byte b;
// to support multi-byte characters
ByteArrayOutputStream baos = new ByteArrayOutputStream();
-int sizeMax = HEADER_PART_SIZE_MAX;
int size = 0;
while (i < HEADER_SEPARATOR.length) {
try {
-b[0] = readByte();
+b = readByte();
} catch (IOException e) {
throw new MalformedStreamException("Stream ended
unexpectedly");
}
-size++;
-if (b[0] == HEADER_SEPARATOR[i]) {
+if (++size > HEADER_PART_SIZE_MAX) {
+throw new MalformedStreamException(
+"Header section has more than " + HEADER_PART_SIZE_MAX
++ " bytes (maybe it is not properly terminated)");
+}
+if (b == HEADER_SEPARATOR[i]) {
i++;
} else {
i = 0;
}
-if (size <= sizeMax) {
-baos.write(b[0]);
-}
+baos.write(b);
}
String headers = null;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r523090 - in /jakarta/commons/proper/fileupload/trunk: ./ src/java/org/apache/commons/fileupload/ src/java/org/apache/commons/fileupload/disk/ src/java/org/apache/commons/fileupload/servle
Author: jochen
Date: Tue Mar 27 14:33:55 2007
New Revision: 523090
URL: http://svn.apache.org/viewvc?view=rev&rev=523090
Log:
Making checkstyle happy.
Modified:
jakarta/commons/proper/fileupload/trunk/pom.xml
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileItemHeadersSupport.java
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadBase.java
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItemFactory.java
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/servlet/FileCleanerCleanup.java
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/util/FileItemHeadersImpl.java
Modified: jakarta/commons/proper/fileupload/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/pom.xml?view=diff&rev=523090&r1=523089&r2=523090
==
--- jakarta/commons/proper/fileupload/trunk/pom.xml (original)
+++ jakarta/commons/proper/fileupload/trunk/pom.xml Tue Mar 27 14:33:55 2007
@@ -243,7 +243,7 @@
org.codehaus.mojo
clirr-maven-plugin
- 1.1
+ 1.2
info
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileItemHeadersSupport.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileItemHeadersSupport.java?view=diff&rev=523090&r1=523089&r2=523090
==
---
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileItemHeadersSupport.java
(original)
+++
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileItemHeadersSupport.java
Tue Mar 27 14:33:55 2007
@@ -31,19 +31,17 @@
* Returns the collection of headers defined locally within this item.
*
* @return the [EMAIL PROTECTED] FileItemHeaders} present for this item.
- * @since 1.3
*/
FileItemHeaders getHeaders();
/**
-* Sets the headers read from within an item. Implementations of
-* [EMAIL PROTECTED] FileItem} or [EMAIL PROTECTED] FileItemStream}
should implement this
-* interface to be able to get the raw headers found within the item
-* header block.
-*
-* @param headers the instance that holds onto the headers
-* for this instance.
-* @since 1.3
-*/
- void setHeaders(FileItemHeaders headers);
+ * Sets the headers read from within an item. Implementations of
+ * [EMAIL PROTECTED] FileItem} or [EMAIL PROTECTED] FileItemStream} should
implement this
+ * interface to be able to get the raw headers found within the item
+ * header block.
+ *
+ * @param headers the instance that holds onto the headers
+ * for this instance.
+ */
+void setHeaders(FileItemHeaders headers);
}
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadBase.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadBase.java?view=diff&rev=523090&r1=523089&r2=523090
==
---
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadBase.java
(original)
+++
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadBase.java
Tue Mar 27 14:33:55 2007
@@ -432,6 +432,11 @@
return getFileName(headers.getHeader(CONTENT_DISPOSITION));
}
+/**
+ * Returns the given content-disposition headers file name.
+ * @param pContentDisposition The content-disposition headers value.
+ * @return The file name
+ */
private String getFileName(String pContentDisposition) {
String fileName = null;
if (pContentDisposition != null) {
@@ -470,9 +475,16 @@
return getFieldName(headers.getHeader(CONTENT_DISPOSITION));
}
+/**
+ * Returns the field name, which is given by the content-disposition
+ * header.
+ * @param pContentDisposition The content-dispositions header value.
+ * @return The field jake
+ */
private String getFieldName(String pContentDisposition) {
String fieldName = null;
-if (pContentDisposition != null &&
pContentDisposition.toLowerCase().startsWith(FORM_DATA)) {
+if (pContentDisposition != null
+&& pContentDisposition.toLowerCase().startsWith(FORM_DATA)) {
svn commit: r523066 - in /jakarta/commons/proper/fileupload/trunk: ./ src/changes/ src/java/org/apache/commons/fileupload/ src/java/org/apache/commons/fileupload/disk/ src/java/org/apache/commons/file
Author: jochen
Date: Tue Mar 27 13:30:53 2007
New Revision: 523066
URL: http://svn.apache.org/viewvc?view=rev&rev=523066
Log:
Adding the ability to get any header from the FileItem and FileItemStream
interfaces.
PR: FILEUPLOAD-130
Submitted-By: Michael Macaluso <[EMAIL PROTECTED]>
Added:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileItemHeaders.java
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileItemHeadersSupport.java
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/util/FileItemHeadersImpl.java
jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/FileItemHeadersTest.java
Modified:
jakarta/commons/proper/fileupload/trunk/.classpath
jakarta/commons/proper/fileupload/trunk/.project
jakarta/commons/proper/fileupload/trunk/pom.xml
jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileItemStream.java
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadBase.java
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java
Modified: jakarta/commons/proper/fileupload/trunk/.classpath
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/.classpath?view=diff&rev=523066&r1=523065&r2=523066
==
--- jakarta/commons/proper/fileupload/trunk/.classpath (original)
+++ jakarta/commons/proper/fileupload/trunk/.classpath Tue Mar 27 13:30:53 2007
@@ -1,8 +1,8 @@
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
Modified: jakarta/commons/proper/fileupload/trunk/.project
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/.project?view=diff&rev=523066&r1=523065&r2=523066
==
--- jakarta/commons/proper/fileupload/trunk/.project (original)
+++ jakarta/commons/proper/fileupload/trunk/.project Tue Mar 27 13:30:53 2007
@@ -1,23 +1,23 @@
-
-
- commons-fileupload
- The FileUpload component provides a simple yet flexible means
of adding support for multipart file upload functionality to servlets and web
applications.
-
-
-
-
- org.eclipse.jdt.core.javabuilder
-
-
-
-
- org.maven.ide.eclipse.maven2Builder
-
-
-
-
-
- org.eclipse.jdt.core.javanature
- org.maven.ide.eclipse.maven2Nature
-
-
+
+
+ commons-fileupload
+ The FileUpload component provides a simple yet flexible means
of adding support for multipart file upload functionality to servlets and web
applications.
+
+
+
+
+ org.eclipse.jdt.core.javabuilder
+
+
+
+
+ org.maven.ide.eclipse.maven2Builder
+
+
+
+
+
+ org.eclipse.jdt.core.javanature
+ org.maven.ide.eclipse.maven2Nature
+
+
Modified: jakarta/commons/proper/fileupload/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/pom.xml?view=diff&rev=523066&r1=523065&r2=523066
==
--- jakarta/commons/proper/fileupload/trunk/pom.xml (original)
+++ jakarta/commons/proper/fileupload/trunk/pom.xml Tue Mar 27 13:30:53 2007
@@ -104,6 +104,10 @@
Henry Yandell
[EMAIL PROTECTED]
+
+ Michael Macaluso
+ [EMAIL PROTECTED]
+
Modified: jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml?view=diff&rev=523066&r1=523065&r2=523066
==
--- jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml (original)
+++ jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml Tue Mar 27
13:30:53 2007
@@ -41,7 +41,7 @@
-
+
Upgrade to commons-io-1.4-SNAPSHOT, in order to use the new
FileCleaningTracker and fix issues with FileCleaner.
@@ -50,6 +50,10 @@
Made the MockHttpServletRequest comply to the servlet 2.4 specification
by applying
http://www.sourcelabs.com/dashboards/sash-1.2/patches/commons-fileupload-1.1-1/SUP-520.diff
+
svn commit: r520302 - in /jakarta/commons/proper/fileupload/trunk: pom.xml project.xml src/changes/changes.xml src/test/org/apache/commons/fileupload/MockHttpServletRequest.java
Author: jochen
Date: Tue Mar 20 00:29:28 2007
New Revision: 520302
URL: http://svn.apache.org/viewvc?view=rev&rev=520302
Log:
Made the MockHttpServletRequest comply to the servlet 2.4 specification
by applying
http://www.sourcelabs.com/dashboards/sash-1.2/patches/commons-fileupload-1.1-1/SUP-520.diff
PR: FILEUPLOAD-129
Modified:
jakarta/commons/proper/fileupload/trunk/pom.xml
jakarta/commons/proper/fileupload/trunk/project.xml
jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml
jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/MockHttpServletRequest.java
Modified: jakarta/commons/proper/fileupload/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/pom.xml?view=diff&rev=520302&r1=520301&r2=520302
==
--- jakarta/commons/proper/fileupload/trunk/pom.xml (original)
+++ jakarta/commons/proper/fileupload/trunk/pom.xml Tue Mar 20 00:29:28 2007
@@ -160,7 +160,7 @@
javax.servlet
servlet-api
- 2.3
+ 2.4
provided
Modified: jakarta/commons/proper/fileupload/trunk/project.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/project.xml?view=diff&rev=520302&r1=520301&r2=520302
==
--- jakarta/commons/proper/fileupload/trunk/project.xml (original)
+++ jakarta/commons/proper/fileupload/trunk/project.xml Tue Mar 20 00:29:28 2007
@@ -180,7 +180,7 @@
javax.servlet
servlet-api
- 2.3
+ 2.4
http://java.sun.com/products/servlet/
provided
Modified: jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml?view=diff&rev=520302&r1=520301&r2=520302
==
--- jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml (original)
+++ jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml Tue Mar 20
00:29:28 2007
@@ -46,6 +46,11 @@
Upgrade to commons-io-1.4-SNAPSHOT, in order to use the new
FileCleaningTracker and fix issues with FileCleaner.
+
+Made the MockHttpServletRequest comply to the servlet 2.4 specification
+by applying
+
http://www.sourcelabs.com/dashboards/sash-1.2/patches/commons-fileupload-1.1-1/SUP-520.diff
+
Modified:
jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/MockHttpServletRequest.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/MockHttpServletRequest.java?view=diff&rev=520302&r1=520301&r2=520302
==
---
jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/MockHttpServletRequest.java
(original)
+++
jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/MockHttpServletRequest.java
Tue Mar 20 00:29:28 2007
@@ -402,6 +402,14 @@
}
/**
+* @see javax.servlet.ServletRequest#getLocalName()
+*/
+ public String getLocalName()
+ {
+ return null;
+ }
+
+/**
* @see javax.servlet.ServletRequest#getServerPort()
*/
public int getServerPort()
@@ -410,6 +418,22 @@
}
/**
+* @see javax.servlet.ServletRequest#getLocalPort()
+*/
+ public int getLocalPort()
+ {
+ return 0;
+ }
+
+ /**
+* @see javax.servlet.ServletRequest#getRemotePort()
+*/
+ public int getRemotePort()
+ {
+ return 0;
+ }
+
+/**
* @see javax.servlet.ServletRequest#getReader()
*/
public BufferedReader getReader() throws IOException
@@ -426,6 +450,14 @@
}
/**
+* @see javax.servlet.ServletRequest#getLocalAddr()
+*/
+ public String getLocalAddr()
+ {
+ return null;
+ }
+
+/**
* @see javax.servlet.ServletRequest#getRemoteHost()
*/
public String getRemoteHost()
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r518944 - in /jakarta/commons/proper/fileupload/trunk: ./ src/java/org/apache/commons/fileupload/ src/main/assembly/ src/site/ src/test/org/apache/commons/fileupload/ xdocs/
Author: jochen
Date: Fri Mar 16 04:47:19 2007
New Revision: 518944
URL: http://svn.apache.org/viewvc?view=rev&rev=518944
Log:
Merged in changes made for the 1.2 release.
Modified:
jakarta/commons/proper/fileupload/trunk/NOTICE.txt
jakarta/commons/proper/fileupload/trunk/pom.xml
jakarta/commons/proper/fileupload/trunk/project.xml
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadBase.java
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java
jakarta/commons/proper/fileupload/trunk/src/main/assembly/src.xml
jakarta/commons/proper/fileupload/trunk/src/site/site.xml
jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/ProgressListenerTest.java
jakarta/commons/proper/fileupload/trunk/xdocs/index.xml
Modified: jakarta/commons/proper/fileupload/trunk/NOTICE.txt
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/NOTICE.txt?view=diff&rev=518944&r1=518943&r2=518944
==
--- jakarta/commons/proper/fileupload/trunk/NOTICE.txt (original)
+++ jakarta/commons/proper/fileupload/trunk/NOTICE.txt Fri Mar 16 04:47:19 2007
@@ -1,5 +1,5 @@
Apache Jakarta Commons FileUpload
-Copyright 2002-2006 The Apache Software Foundation
+Copyright 2002-2007 The Apache Software Foundation
This product includes software developed by
The Apache Software Foundation (http://www.apache.org/).
Modified: jakarta/commons/proper/fileupload/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/pom.xml?view=diff&rev=518944&r1=518943&r2=518944
==
--- jakarta/commons/proper/fileupload/trunk/pom.xml (original)
+++ jakarta/commons/proper/fileupload/trunk/pom.xml Fri Mar 16 04:47:19 2007
@@ -235,6 +235,14 @@
+
+org.codehaus.mojo
+clirr-maven-plugin
+
+ 1.1
+ info
+
+
Modified: jakarta/commons/proper/fileupload/trunk/project.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/project.xml?view=diff&rev=518944&r1=518943&r2=518944
==
--- jakarta/commons/proper/fileupload/trunk/project.xml (original)
+++ jakarta/commons/proper/fileupload/trunk/project.xml Fri Mar 16 04:47:19 2007
@@ -79,7 +79,7 @@
1.2
- 1.1.1
+ 1.2
commons-fileupload-1.2
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadBase.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadBase.java?view=diff&rev=518944&r1=518943&r2=518944
==
---
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadBase.java
(original)
+++
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadBase.java
Fri Mar 16 04:47:19 2007
@@ -342,7 +342,8 @@
List items = new ArrayList();
FileItemFactory fac = getFileItemFactory();
if (fac == null) {
-throw new NullPointerException("No FileItemFactory has been
set.");
+throw new NullPointerException(
+"No FileItemFactory has been set.");
}
while (iter.hasNext()) {
FileItemStream item = iter.next();
@@ -1114,14 +1115,17 @@
private static final long serialVersionUID = -2474893167098052828L;
/**
- * @deprecated Replaced by [EMAIL PROTECTED]
#SizeLimitExceededException(String, long, long)}
+ * @deprecated Replaced by
+ * [EMAIL PROTECTED] #SizeLimitExceededException(String, long, long)}
*/
public SizeLimitExceededException() {
this(null, 0, 0);
}
/**
- * @deprecated Replaced by [EMAIL PROTECTED]
#SizeLimitExceededException(String, long, long)}
+ * @deprecated Replaced by
+ * [EMAIL PROTECTED] #SizeLimitExceededException(String, long, long)}
+ * @param message The exceptions detail message.
*/
public SizeLimitExceededException(String message) {
this(message, 0, 0);
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java?view=diff&rev=518944&r1=518943&r2=518944
======
svn commit: r518775 - in /jakarta/commons/proper/fileupload/trunk: ./ src/java/org/apache/commons/fileupload/disk/ src/java/org/apache/commons/fileupload/servlet/ xdocs/
Author: jochen
Date: Thu Mar 15 15:05:19 2007
New Revision: 518775
URL: http://svn.apache.org/viewvc?view=rev&rev=518775
Log:
Using the FileCleaningTracker now.
Modified:
jakarta/commons/proper/fileupload/trunk/pom.xml
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItemFactory.java
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/servlet/FileCleanerCleanup.java
jakarta/commons/proper/fileupload/trunk/xdocs/using.xml
Modified: jakarta/commons/proper/fileupload/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/pom.xml?view=diff&rev=518775&r1=518774&r2=518775
==
--- jakarta/commons/proper/fileupload/trunk/pom.xml (original)
+++ jakarta/commons/proper/fileupload/trunk/pom.xml Thu Mar 15 15:05:19 2007
@@ -172,7 +172,7 @@
commons-io
commons-io
- 1.3
+ 1.4-SNAPSHOT
true
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java?view=diff&rev=518775&r1=518774&r2=518775
==
---
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java
(original)
+++
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java
Thu Mar 15 15:05:19 2007
@@ -29,6 +29,8 @@
import java.io.ObjectInputStream;
import java.io.UnsupportedEncodingException;
import java.util.Map;
+
+import org.apache.commons.io.FileCleaningTracker;
import org.apache.commons.io.IOUtils;
import org.apache.commons.io.FileCleaner;
import org.apache.commons.io.output.DeferredFileOutputStream;
@@ -77,6 +79,11 @@
// - Manifest constants
+/**
+ * The UID to use when serializing this instance.
+ */
+private static final long serialVersionUID = 2237570099615271025L;
+
/**
* Default content charset to be used when no explicit charset
@@ -163,6 +170,10 @@
*/
private File dfosFile;
+/**
+ * The tracker, which is responsible for deleting the temporary file.
+ */
+private FileCleaningTracker fileCleaningTracker;
// --- Constructors
@@ -183,10 +194,38 @@
* @param repositoryThe data repository, which is the directory in
* which files will be created, should the item size
* exceed the threshold.
+ * @deprecated Use [EMAIL PROTECTED] #DiskFileItem(FileCleaningTracker,
String, String, boolean, String, int, File)}.
*/
public DiskFileItem(String fieldName, String contentType,
boolean isFormField, String fileName, int sizeThreshold,
File repository) {
+this(FileCleaner.getInstance(), fieldName, contentType,
+isFormField, fileName, sizeThreshold,
+repository);
+}
+
+/**
+ * Constructs a new DiskFileItem instance.
+ *
+ * @param tracker The tracker, which is responsible for deleting
+ * the temporary file.
+ * @param fieldName The name of the form field.
+ * @param contentType The content type passed by the browser or
+ * null if not specified.
+ * @param isFormField Whether or not this item is a plain form field, as
+ * opposed to a file upload.
+ * @param fileName The original filename in the user's filesystem, or
+ * null if not specified.
+ * @param sizeThreshold The threshold, in bytes, below which items will be
+ * retained in memory and above which they will be
+ * stored as a file.
+ * @param repositoryThe data repository, which is the directory in
+ * which files will be created, should the item size
+ * exceed the threshold.
+ */
+private DiskFileItem(FileCleaningTracker tracker, String fieldName, String
contentType,
+boolean isFormField, String fileName, int sizeThreshold, File
repository) {
+this.fileCleaningTracker = tracker;
this.fieldName = fieldName;
this.contentType = contentType;
this.isFormField = isFormField;
@@ -195,6 +234,25 @@
this.repository = repository;
}
+/**
+ * Constructs a new DiskFileItem instance.
+ *
+ * @param factory Th
[jira] Resolved: (FILEUPLOAD-128) move commons-fileupload to org.apache.commons.fileupload groupId in maven
[ https://issues.apache.org/jira/browse/FILEUPLOAD-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved FILEUPLOAD-128. Resolution: Fixed The groupId is already changed in the trunk. In other words, 1.3 will have this groupId. As for 1.2, we have no intentions to change anything. > move commons-fileupload to org.apache.commons.fileupload groupId in maven > - > > Key: FILEUPLOAD-128 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-128 > Project: Commons FileUpload > Issue Type: Improvement >Reporter: Henning Schmiedehausen > > Currently, the 1.2 release of c-f is located at > http://people.apache.org/repo/m2-ibiblio-rsync-repository/commons-fileupload/ > It is probably better off at > http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/commons/fileupload/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (FILEUPLOAD-128) move commons-fileupload to org.apache.commons.fileupload groupId in maven
move commons-fileupload to org.apache.commons.fileupload groupId in maven - Key: FILEUPLOAD-128 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-128 Project: Commons FileUpload Issue Type: Improvement Reporter: Henning Schmiedehausen Currently, the 1.2 release of c-f is located at http://people.apache.org/repo/m2-ibiblio-rsync-repository/commons-fileupload/ It is probably better off at http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/commons/fileupload/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (FILEUPLOAD-127) distribution mirrors looking for commons-fileupload-1.2.tar.gz but file is named commons-fileupload-1.2-bin.tar.gz
[ https://issues.apache.org/jira/browse/FILEUPLOAD-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved FILEUPLOAD-127. Resolution: Fixed Fixed thanks http://svn.apache.org/viewvc?view=rev&revision=515366 > distribution mirrors looking for commons-fileupload-1.2.tar.gz but file is > named commons-fileupload-1.2-bin.tar.gz > -- > > Key: FILEUPLOAD-127 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-127 > Project: Commons FileUpload > Issue Type: Bug > Environment: all >Reporter: Ron Ridgely > Fix For: 1.2 > > > Distribution mirrors looking for "commons-fileupload-1.2.tar.gz" but file is > named "commons-fileupload-1.2-bin.tar.gz" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (FILEUPLOAD-127) distribution mirrors looking for commons-fileupload-1.2.tar.gz but file is named commons-fileupload-1.2-bin.tar.gz
[ https://issues.apache.org/jira/browse/FILEUPLOAD-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478615 ] Jochen Wiedmann commented on FILEUPLOAD-127: Are you referring to a broken link? If so, on what page? > distribution mirrors looking for commons-fileupload-1.2.tar.gz but file is > named commons-fileupload-1.2-bin.tar.gz > -- > > Key: FILEUPLOAD-127 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-127 > Project: Commons FileUpload > Issue Type: Bug > Environment: all >Reporter: Ron Ridgely > Fix For: 1.2 > > > Distribution mirrors looking for "commons-fileupload-1.2.tar.gz" but file is > named "commons-fileupload-1.2-bin.tar.gz" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (FILEUPLOAD-127) distribution mirrors looking for commons-fileupload-1.2.tar.gz but file is named commons-fileupload-1.2-bin.tar.gz
distribution mirrors looking for commons-fileupload-1.2.tar.gz but file is named commons-fileupload-1.2-bin.tar.gz -- Key: FILEUPLOAD-127 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-127 Project: Commons FileUpload Issue Type: Bug Environment: all Reporter: Ron Ridgely Fix For: 1.2 Distribution mirrors looking for "commons-fileupload-1.2.tar.gz" but file is named "commons-fileupload-1.2-bin.tar.gz" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Announce: Commons Fileupload 1.2
On 2/24/07, Martin van den Bemt <[EMAIL PROTECTED]> wrote: Please update the http://wiki.apache.org/jakarta/JakartaBoardReport-current (section releases and the section of the fileupload component, with some more details about the release) Done. -- Emacs 22 will support MacOS and CygWin. It is not yet decided, whether these will be used to run Emacs or the other way round. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Announce: Commons Fileupload 1.2
Jochen, Please update the http://wiki.apache.org/jakarta/JakartaBoardReport-current (section releases and the section of the fileupload component, with some more details about the release) Mvgr, Martin Jochen Wiedmann wrote: > Hi, > > the Jakarta Commons team is glad to announce the availability of > commons-fileupload 1.2. Commons Fileupload is a framework for handling > HTTP file upload requests in servlets, portlets, and similar server > side Java applications. > > Compared to the previous version 1.1.1, the following notable changes > have been made: > > - A streaming API has been added. The streaming API allows to handle > arbitrarily > large files without intermediary files while still keeping an > extremely low memory > profile. > - The presence of a content-length header is no longer required. > - Added support for progress listeners. > - Added support for header continuation lines. > - Added support for limiting the actual file size, as opposed to the > request size. > > Commons Fileupload 1.2 is available from > > > http://jakarta.apache.org/site/downloads/downloads_commons-fileupload.cgi > > > Jochen Wiedmann > > - > 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]
Announce: Commons Fileupload 1.2
Hi, the Jakarta Commons team is glad to announce the availability of commons-fileupload 1.2. Commons Fileupload is a framework for handling HTTP file upload requests in servlets, portlets, and similar server side Java applications. Compared to the previous version 1.1.1, the following notable changes have been made: - A streaming API has been added. The streaming API allows to handle arbitrarily large files without intermediary files while still keeping an extremely low memory profile. - The presence of a content-length header is no longer required. - Added support for progress listeners. - Added support for header continuation lines. - Added support for limiting the actual file size, as opposed to the request size. Commons Fileupload 1.2 is available from http://jakarta.apache.org/site/downloads/downloads_commons-fileupload.cgi Jochen Wiedmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r510126 - /jakarta/commons/proper/fileupload/tags/commons-fileupload-1.2/
Author: jochen Date: Wed Feb 21 10:04:33 2007 New Revision: 510126 URL: http://svn.apache.org/viewvc?view=rev&rev=510126 Log: Release of 1.2 Added: jakarta/commons/proper/fileupload/tags/commons-fileupload-1.2/ - copied from r510125, jakarta/commons/proper/fileupload/tags/commons-fileupload-1.2rc4/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] Release commons-fileupload 1.2 (4th attempt)
Hi,. result of the vote to release commons-fileupload 1.2rc4: [+1] 6 binding (Dims, Oliver, Henri, Joerg, Niall, myself), 1 non-binding (Lennard) I'll publish the release today. Jochen -- Emacs 22 will support MacOS and CygWin. It is not yet decided, whether these will be used to run Emacs or the other way round. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-fileupload 1.2 (4th attempt)
Stephen Colebourne wrote: > Jochen Wiedmann wrote: >> On 2/16/07, Jörg Schaible <[EMAIL PROTECTED]> wrote: >> >>> > (1) The md5 files do not contain the file name, which is standard for >>> > commons components (see section 2 of [1]). >>> >>> This is the way Maven 2 generates *and* checks it. So if you change >>> those, I >>> am quite sure, that every M2 user will get always a warning because of >>> the >>> checksum! >> >> I believe that Olivers and your concerms can be resolved by proposing >> that the files that go into /www/www.apache.org/dist are distributed >> as proposed by Oliver. OTOH, the files that go into the Maven >> repository won't have a file name. > > See commons-io in the maven2 repository: > http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-io/commons-io/1.3/commons-io-1.3.jar.md5 > > The *filename part is present. > > Does it cause any issues? I don't know, I don't use maven 2. I doubt it > though as no ones ever complained. Well, I said *if* any user gets a warning I am -1 to such a change. Honestly I don't know either, but M2 is not the only software anymore accessing the public repos. Interfering in the way the deploy plugin works is at current stage a major hassle and IMHO not worth to prevent a release. If we wanna have such a change, we have to change the way the plugin works. - Jörg - Jörg > > Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-fileupload 1.2 (4th attempt)
On 2/14/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: [X] +1 [ ] =0 [ ] -1 I do have a few comments on the site/docs - none of which IMO should prevent the release - and my +1 vote is unconditional. There are a couple of maven2 issues with the site generation which makes me think that it might be better to exclude the site from the distro (just including the JavaDocs): - Links are being converted to relative ones, so for example the Commons & Jakarta links don't work for the site/docs included in the distro. - The changes report for m2 doesn't like html markup and entries that have it appear as blank. For fileupload there are a few such blank entries in the previous releases section. I can understand you wanting to get the release out and not wait for the next Commons POM release - it does mean that the site/docs don't have the standard Commons L&F and perhaps another reason for excluding them - but as long as that isn't whats published as the FileUpload web site, thats the main thing. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-fileupload 1.2 (4th attempt)
Jochen Wiedmann wrote: On 2/16/07, Jörg Schaible <[EMAIL PROTECTED]> wrote: > (1) The md5 files do not contain the file name, which is standard for > commons components (see section 2 of [1]). This is the way Maven 2 generates *and* checks it. So if you change those, I am quite sure, that every M2 user will get always a warning because of the checksum! I believe that Olivers and your concerms can be resolved by proposing that the files that go into /www/www.apache.org/dist are distributed as proposed by Oliver. OTOH, the files that go into the Maven repository won't have a file name. See commons-io in the maven2 repository: http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-io/commons-io/1.3/commons-io-1.3.jar.md5 The *filename part is present. Does it cause any issues? I don't know, I don't use maven 2. I doubt it though as no ones ever complained. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-fileupload 1.2 (4th attempt)
On 2/16/07, Jörg Schaible <[EMAIL PROTECTED]> wrote: > (1) The md5 files do not contain the file name, which is standard for > commons components (see section 2 of [1]). This is the way Maven 2 generates *and* checks it. So if you change those, I am quite sure, that every M2 user will get always a warning because of the checksum! I believe that Olivers and your concerms can be resolved by proposing that the files that go into /www/www.apache.org/dist are distributed as proposed by Oliver. OTOH, the files that go into the Maven repository won't have a file name. Jochen -- Emacs 22 will support MacOS and CygWin. It is not yet decided, whether these will be used to run Emacs or the other way round. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-fileupload 1.2 (4th attempt)
+1 building from source in Gentoo Linux with Maven 1, all tests pass for all my JDK's (1.3.1 to 1.6 from various vendors). - Jörg Jochen Wiedmann wrote: > Hi, > > this is going to kill me, but I'd like to call for a release of > commons-fileupload 1.2 once more. Commons-fileupload-1.2rc4 is > available from > > http://people.apache.org/~jochen/commons-fileupload/dist > > The generated site is at > > http://people.apache.org/~jochen/commons-fileupload/dist > > The SVN tag is > > commons-fileupload-1.2rc4 > > Compared to rc3, the following things have been changed: > > * The LICENSE.txt and NOTICE.txt files are now added to all jar files. > (They had been added before, but been overwritten when the assemblies > have been created.) > * A workaround for a bug in the maven-site-plugin has been added. > This bug prevented static resources being added. In particular, the > logo of the commons-fileupload project was missing. > * The RAT report is now added to the projects reports. > * The clirr report is now also added to the project reports. (No idea > why this wasn't the case before.) > > Thanks, > > Jochen > > > [ ] +1 > [ ] =0 > [ ] -1 > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-fileupload 1.2 (4th attempt)
Oliver Heger wrote: > Two minor points: > > (1) The md5 files do not contain the file name, which is standard for > commons components (see section 2 of [1]). This is the way Maven 2 generates *and* checks it. So if you change those, I am quite sure, that every M2 user will get always a warning because of the checksum! [snip] > (2) In the jar generated by the ant build the LICENSE is missing. > > (2) is probably less important for components that use maven as > preferred build tool. I am not sure how important (1) is. > > Otherwise everything looks good. So I am +1 when (1) is fixed. If every user gets a warning when this is fixed, I am -1 on this fix :D [snip] - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-fileupload 1.2 (4th attempt)
On 2/13/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: [X] +1 [ ] =0 [ ] -1 Site: * Date obviously needs to be fixed on front page of website once the release goes out. * It'd be useful if the Streaming API page mentions that it arrived in 1.2. * Linking to http://jakarta.apache.org/site/downloads/downloads_commons-fileupload.cgi on the lhs navbar would be good. None are blocking (as they can be fixed after the fact). Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-fileupload 1.2 (4th attempt)
Two minor points: (1) The md5 files do not contain the file name, which is standard for commons components (see section 2 of [1]). (2) In the jar generated by the ant build the LICENSE is missing. (2) is probably less important for components that use maven as preferred build tool. I am not sure how important (1) is. Otherwise everything looks good. So I am +1 when (1) is fixed. Oliver [1] http://jakarta.apache.org/commons/releases/release.html Jochen Wiedmann wrote: Hi, this is going to kill me, but I'd like to call for a release of commons-fileupload 1.2 once more. Commons-fileupload-1.2rc4 is available from http://people.apache.org/~jochen/commons-fileupload/dist The generated site is at http://people.apache.org/~jochen/commons-fileupload/dist The SVN tag is commons-fileupload-1.2rc4 Compared to rc3, the following things have been changed: * The LICENSE.txt and NOTICE.txt files are now added to all jar files. (They had been added before, but been overwritten when the assemblies have been created.) * A workaround for a bug in the maven-site-plugin has been added. This bug prevented static resources being added. In particular, the logo of the commons-fileupload project was missing. * The RAT report is now added to the projects reports. * The clirr report is now also added to the project reports. (No idea why this wasn't the case before.) Thanks, Jochen [ ] +1 [ ] =0 [ ] -1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-fileupload 1.2 (4th attempt)
+1 Jochen Wiedmann wrote: Hi, this is going to kill me, but I'd like to call for a release of commons-fileupload 1.2 once more. Commons-fileupload-1.2rc4 is available from http://people.apache.org/~jochen/commons-fileupload/dist The generated site is at http://people.apache.org/~jochen/commons-fileupload/dist The SVN tag is commons-fileupload-1.2rc4 Compared to rc3, the following things have been changed: * The LICENSE.txt and NOTICE.txt files are now added to all jar files. (They had been added before, but been overwritten when the assemblies have been created.) * A workaround for a bug in the maven-site-plugin has been added. This bug prevented static resources being added. In particular, the logo of the commons-fileupload project was missing. * The RAT report is now added to the projects reports. * The clirr report is now also added to the project reports. (No idea why this wasn't the case before.) Thanks, Jochen [ ] +1 [ ] =0 [ ] -1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-fileupload 1.2 (4th attempt)
+1
On 2/13/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
Hi,
this is going to kill me, but I'd like to call for a release of
commons-fileupload 1.2 once more. Commons-fileupload-1.2rc4 is
available from
http://people.apache.org/~jochen/commons-fileupload/dist
The generated site is at
http://people.apache.org/~jochen/commons-fileupload/dist
The SVN tag is
commons-fileupload-1.2rc4
Compared to rc3, the following things have been changed:
* The LICENSE.txt and NOTICE.txt files are now added to all jar files.
(They had been added before, but been overwritten when the assemblies
have been created.)
* A workaround for a bug in the maven-site-plugin has been added.
This bug prevented static resources being added. In particular, the
logo of the commons-fileupload project was missing.
* The RAT report is now added to the projects reports.
* The clirr report is now also added to the project reports. (No idea
why this wasn't the case before.)
Thanks,
Jochen
[ ] +1
[ ] =0
[ ] -1
--
How fast can a year go? As fast as your childs first year.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
PMC Members: Please vote for commons-fileupload
Hi, PMC members, please have a look at http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=117142900222167&w=2 as you all know, a release needs at least three positive votes from PMC members before being released. So far this vote hasn't got any votes. In particular not from PMC members. Thanks, Jochen -- Emacs 22 will support MacOS and CygWin. It is not yet decided, whether these will be used to run Emacs or the other way round. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release commons-fileupload 1.2 (4th attempt)
Hi, this is going to kill me, but I'd like to call for a release of commons-fileupload 1.2 once more. Commons-fileupload-1.2rc4 is available from http://people.apache.org/~jochen/commons-fileupload/dist The generated site is at http://people.apache.org/~jochen/commons-fileupload/dist The SVN tag is commons-fileupload-1.2rc4 Compared to rc3, the following things have been changed: * The LICENSE.txt and NOTICE.txt files are now added to all jar files. (They had been added before, but been overwritten when the assemblies have been created.) * A workaround for a bug in the maven-site-plugin has been added. This bug prevented static resources being added. In particular, the logo of the commons-fileupload project was missing. * The RAT report is now added to the projects reports. * The clirr report is now also added to the project reports. (No idea why this wasn't the case before.) Thanks, Jochen [ ] +1 [ ] =0 [ ] -1 -- How fast can a year go? As fast as your childs first year. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r507386 - /jakarta/commons/proper/fileupload/tags/commons-fileupload-1.2rc4/
Author: jochen Date: Tue Feb 13 20:48:41 2007 New Revision: 507386 URL: http://svn.apache.org/viewvc?view=rev&rev=507386 Log: (empty) Added: jakarta/commons/proper/fileupload/tags/commons-fileupload-1.2rc4/ - copied from r507385, jakarta/commons/proper/fileupload/branches/b1_2/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r505770 - /jakarta/commons/proper/fileupload/branches/b1_2/src/test/org/apache/commons/fileupload/ProgressListenerTest.java
Author: jochen
Date: Sat Feb 10 13:35:17 2007
New Revision: 505770
URL: http://svn.apache.org/viewvc?view=rev&rev=505770
Log:
Workaround for a problem with the JRockit JRE.
Modified:
jakarta/commons/proper/fileupload/branches/b1_2/src/test/org/apache/commons/fileupload/ProgressListenerTest.java
Modified:
jakarta/commons/proper/fileupload/branches/b1_2/src/test/org/apache/commons/fileupload/ProgressListenerTest.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/branches/b1_2/src/test/org/apache/commons/fileupload/ProgressListenerTest.java?view=diff&rev=505770&r1=505769&r2=505770
==
---
jakarta/commons/proper/fileupload/branches/b1_2/src/test/org/apache/commons/fileupload/ProgressListenerTest.java
(original)
+++
jakarta/commons/proper/fileupload/branches/b1_2/src/test/org/apache/commons/fileupload/ProgressListenerTest.java
Sat Feb 10 13:35:17 2007
@@ -90,7 +90,17 @@
FileItemStream stream = iter.next();
InputStream istream = stream.openStream();
for (int j = 0; j < 16384+i; j++) {
- assertEquals((byte) j, (byte) istream.read());
+ /**
+ * This used to be
+ * assertEquals((byte) j, (byte) istream.read());
+ * but this seems to trigger a bug in JRockit, so
+ * we express the same like this:
+*/
+byte b1 = (byte) j;
+byte b2 = (byte) istream.read();
+if (b1 != b2) {
+fail("Expected " + b1 + ", got " + b2);
+}
}
assertEquals(-1, istream.read());
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Release commons-fileupload 1.2 (3rd attempt)
Jochen Wiedmann wrote:
> Hi, Jörg,
>
> On 2/10/07, Jörg Schaible <[EMAIL PROTECTED]> wrote:
>
>> well, I tried hard to find the cause for this, but failed so far. If you
>> look at the stack trace, it simply does not make sense also. Nevertheless
>> when I run the test from within Eclipse with the JRockit 1.5 runtime, the
>> ProgressListenerTest fails every 2nd execution in exactly the reported
>> way. Due to some sysouts I know now, that it happens when the runTest is
>> called the 2nd time *after* the first call to the listener. Unfortunately
>> if you try to debug it, everything seems to work well. OTOH I am quite
>> unfamiliar with the code ...
>>
>> Maybe you wanna try it youself, JRockit can be freely downloaded at
>> http://commerce.bea.com/products/weblogicjrockit/jrockit_prod_fam.jsp
>
> Could you please replace line 93 in the ProgressListenerTest with the
> following:
>
> /**
> * This used to be
> * assertEquals((byte) j, (byte) istream.read());
> * but this seems to trigger a bug in JRockit, so
> * we express the same like this:
> */
> byte b1 = (byte) j;
> byte b2 = (byte) istream.read();
> if (b1 != b2) {
> fail("Expected " + b1 + ", got " + b2);
> }
>
> That seems to work for me, for whatever reason.
Same here. Strange. Well, so this is definitely nothing that should prevent
this release
+1
- Jörg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Release commons-fileupload 1.2 (3rd attempt)
Hi, Jörg,
On 2/10/07, Jörg Schaible <[EMAIL PROTECTED]> wrote:
well, I tried hard to find the cause for this, but failed so far. If you
look at the stack trace, it simply does not make sense also. Nevertheless
when I run the test from within Eclipse with the JRockit 1.5 runtime, the
ProgressListenerTest fails every 2nd execution in exactly the reported way.
Due to some sysouts I know now, that it happens when the runTest is called
the 2nd time *after* the first call to the listener. Unfortunately if you
try to debug it, everything seems to work well. OTOH I am quite unfamiliar
with the code ...
Maybe you wanna try it youself, JRockit can be freely downloaded at
http://commerce.bea.com/products/weblogicjrockit/jrockit_prod_fam.jsp
Could you please replace line 93 in the ProgressListenerTest with the following:
/**
* This used to be
* assertEquals((byte) j, (byte) istream.read());
* but this seems to trigger a bug in JRockit, so
* we express the same like this:
*/
byte b1 = (byte) j;
byte b2 = (byte) istream.read();
if (b1 != b2) {
fail("Expected " + b1 + ", got " + b2);
}
That seems to work for me, for whatever reason.
Jochen
--
How fast can a year go? As fast as your childs first year.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Release commons-fileupload 1.2 (3rd attempt)
Hi Jochen, Jochen Wiedmann wrote: > On 2/9/07, Jörg Schaible <[EMAIL PROTECTED]> wrote: > >> testProgressListener(org.apache.commons.fileupload.ProgressListenerTest): >> FAILED >> expected:<-128> but was:<-128> > > This sounds like two different kinds of objects with "same" values, > for example (short) -128 as opposed to (int) -128. Yeah, but it does not make sense. The error message indicated, that an assertion failed and in that code I cannot see anywhere a call with an Object, assertXXX it is always called with the native types. > Could you please be so kind to add some logging code that checks this? well, I tried hard to find the cause for this, but failed so far. If you look at the stack trace, it simply does not make sense also. Nevertheless when I run the test from within Eclipse with the JRockit 1.5 runtime, the ProgressListenerTest fails every 2nd execution in exactly the reported way. Due to some sysouts I know now, that it happens when the runTest is called the 2nd time *after* the first call to the listener. Unfortunately if you try to debug it, everything seems to work well. OTOH I am quite unfamiliar with the code ... Maybe you wanna try it youself, JRockit can be freely downloaded at http://commerce.bea.com/products/weblogicjrockit/jrockit_prod_fam.jsp - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Release commons-fileupload 1.2 (3rd attempt)
On 2/9/07, Jörg Schaible <[EMAIL PROTECTED]> wrote: testProgressListener(org.apache.commons.fileupload.ProgressListenerTest): FAILED expected:<-128> but was:<-128> This sounds like two different kinds of objects with "same" values, for example (short) -128 as opposed to (int) -128. Could you please be so kind to add some logging code that checks this? Thanks, Jochen -- How fast can a year go? As fast as your childs first year. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Release commons-fileupload 1.2 (3rd attempt)
Hi Jochen, I've running the tests from the sources in Gentoo Linux with Maven 1 and the JDKs: - Sun JDK 1.6.0 - Sun JDK 1.5.0 - Blackdown JDK 1.4.2 - IBM JDK 1.5.0 - JRockit JDK 1.5.0 Nevertheless JRockit fails half of the time here with an obscure failure. I also see the IBM JDK with an extreme long duration time (3-4 times longer than Sun) for this test (although it succeeds in the end). The test seems somewhat brittle. = %< Testsuite: org.apache.commons.fileupload.ProgressListenerTest Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 11,019 sec Testcase: testProgressListener(org.apache.commons.fileupload.ProgressListenerTest): FAILED expected:<-128> but was:<-128> junit.framework.AssertionFailedError: expected:<-128> but was:<-128> at org.apache.commons.fileupload.ProgressListenerTest.runTest(ProgressListenerTest.java:85) at org.apache.commons.fileupload.ProgressListenerTest.testProgressListener(ProgressListenerTest.java:81) at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object [Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source) at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:185) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.Goal.attainPrecursors(Goal.java:488) = %< - Jörg Jochen Wiedmann wrote: > Hi, > > I have prepared commons-fileupload-1.2rc3. Compared to 1.2rc2, the > following changes have been made: > > - The sources are now available as tar.gz and .zip file. > - The build has been made with JDK 1.5.0_11, rather than 1.6.0rc1. > > Please note, that this release (like all releases) requires, in > particular, 3 positive votes from PMC members. > > Thanks, > > Jochen > > > [ ] +1 > [ ] =0 > [ ] -1 > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Release commons-fileupload 1.2 (3rd attempt)
Henri Yandell wrote: On 2/7/07, Stephen Colebourne <[EMAIL PROTECTED]> wrote: LICENSE and NOTICE missing from -sources.jar and -javadoc.jar Shouldn't be hard for Jochen to fix this prior to release. Website has lost a lot of stuff compared to existing website A lot of stuff. An odd logo for Commons, missing logo for FileUpload, missing ApacheCon advert, missing Commons items on the LHS. The .pom file is an M2 pom, so we need to make sure it goes to the m2 ibiblio repo and not the m1 ibiblio repo [I'm sure you know that Jochen, just stating the obvious as it never hurts]. PGP sig checks out. MD5s are good. The build.xml is odd - it gets jars from repo1.maven.org (good) and then tries to get them from the apache snapshot repo. That's odd - I'm guessing this is a bug in the Maven build.xml plugin? Not a blocker. Without looking actually looking at the code in question, I think it is working as expected. If fileupload or any of its ancestors declare the snapshot repo as a place to look for artifacts, I think it should be used by the ant build as well. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Release commons-fileupload 1.2 (3rd attempt)
On 2/7/07, Stephen Colebourne <[EMAIL PROTECTED]> wrote: LICENSE and NOTICE missing from -sources.jar and -javadoc.jar Shouldn't be hard for Jochen to fix this prior to release. Website has lost a lot of stuff compared to existing website A lot of stuff. An odd logo for Commons, missing logo for FileUpload, missing ApacheCon advert, missing Commons items on the LHS. The .pom file is an M2 pom, so we need to make sure it goes to the m2 ibiblio repo and not the m1 ibiblio repo [I'm sure you know that Jochen, just stating the obvious as it never hurts]. PGP sig checks out. MD5s are good. The build.xml is odd - it gets jars from repo1.maven.org (good) and then tries to get them from the apache snapshot repo. That's odd - I'm guessing this is a bug in the Maven build.xml plugin? Not a blocker. Src rebuilds happily under ant, maven1 + maven2. The checkstyle report has 2 'errors'. I don't see the clirr report. Blockers: * Site * Clirr report Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Release commons-fileupload 1.2 (3rd attempt)
Hi, in addition to the points Stephen has already mentioned: - The source distro deflates into the same directory as the binary distro. It is common practice to name the directory "commons-fileupload-1.2rc3-src". - I tested the builds with maven 1, 2, and ant. They all work, but when building with ant the LICENSE is missing from the jar and the manifest does not contain the usual entries. I don't think these points are show stoppers, but they should be easy to fix. Oliver Jochen Wiedmann wrote: On 2/7/07, Oliver Heger <[EMAIL PROTECTED]> wrote: Hm, I probably did not follow this thread in the past, so can you please point me to where I find the files of this rc? Awfully sorry, and thanks for asking. The files are available from http://people.apache.org/~jochen/commons-fileupload/dist/ A file rat.txt (RAT report) is included. The proposed site is at http://people.apache.org/~jochen/commons-fileupload/site/ Clirr and checkstyle reports are included in the site. Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven 2 (WAS: [VOTE] commons-fileupload 1.2 (rc2))
Hi Dennis, Dennis Lundberg wrote on Wednesday, February 07, 2007 9:39 PM: [snip] >>> I put together this document when I was trying to pull through the >>> whole groupId change last time: >>> >>>http://maven.apache.org/guides/mini/guide-relocation.html >>> >>> There is never a good time to change the groupId. My view is that we >>> should do it when we move to M2, both as a build tool and as the >>> target repository. >> >> Yes, I tried to use this description for a M1 -> M2 situation. In >> the end Carlos' advice was to ignore all the old versions and simply >> start with the new M2 releases also to use the new groupId and add >> for those releases only a relocation POM. > > That is a much easier way to do it. I'm starting to think > that this is > the way to go for Commons. Just change the groupId when we release > with M2 and don't relocate older versions. Yep. If we agree all on this, we can immediately start to use the new groupId. It's just, that the release & deploy process will not automatically create those relocation POMs. >> The problem with adjusting the old releases is, that the >> location for the relocation POMs is already occupied by the >> automatically generated POMs for M2 on the global M2 repo (see >> > http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-logging/ > commons-logging/1.1/). >> And since they're already published, they cannot be changed anymore. > > I think you are allowed to add a relocation section to an already > published pom. I vaguely remember discussing this with Carlos back > then. Well, it seems, they become more strict since then. I got definitely a negative answer from him as to replace the old POMs from ibiblio with the ones including the relocation section available on a synchronized site. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Release commons-fileupload 1.2 (3rd attempt)
LICENSE and NOTICE missing from -sources.jar and -javadoc.jar Website has lost a lot of stuff compared to existing website Stephen Jochen Wiedmann wrote: On 2/7/07, Oliver Heger <[EMAIL PROTECTED]> wrote: Hm, I probably did not follow this thread in the past, so can you please point me to where I find the files of this rc? Awfully sorry, and thanks for asking. The files are available from http://people.apache.org/~jochen/commons-fileupload/dist/ A file rat.txt (RAT report) is included. The proposed site is at http://people.apache.org/~jochen/commons-fileupload/site/ Clirr and checkstyle reports are included in the site. Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Release commons-fileupload 1.2 (3rd attempt)
On 2/7/07, Oliver Heger <[EMAIL PROTECTED]> wrote: Hm, I probably did not follow this thread in the past, so can you please point me to where I find the files of this rc? Awfully sorry, and thanks for asking. The files are available from http://people.apache.org/~jochen/commons-fileupload/dist/ A file rat.txt (RAT report) is included. The proposed site is at http://people.apache.org/~jochen/commons-fileupload/site/ Clirr and checkstyle reports are included in the site. Jochen -- How fast can a year go? As fast as your childs first year. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Release commons-fileupload 1.2 (3rd attempt)
Hm, I probably did not follow this thread in the past, so can you please point me to where I find the files of this rc? Thanks Oliver Jochen Wiedmann wrote: Hi, I have prepared commons-fileupload-1.2rc3. Compared to 1.2rc2, the following changes have been made: - The sources are now available as tar.gz and .zip file. - The build has been made with JDK 1.5.0_11, rather than 1.6.0rc1. Please note, that this release (like all releases) requires, in particular, 3 positive votes from PMC members. Thanks, Jochen [ ] +1 [ ] =0 [ ] -1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2 (WAS: [VOTE] commons-fileupload 1.2 (rc2))
Jörg Schaible wrote: Hi Dennis, Dennis Lundberg wrote: Henri Yandell wrote: On 2/5/07, Jörg Schaible <[EMAIL PROTECTED]> wrote: Hi Jochen, Jochen Wiedmann wrote on Monday, February 05, 2007 9:03 AM: I'm thinking: * Change group id? Couldn't we do that *after* the release, please? I would clearly prefer *not* to introduce any incompatible changes in that stage. +1 from my personal experience with a different project all I can say is that changing the groupId is a task that is not very well supported by M2. The available docs are spare, do not work as they are described or are out of date. So changing the groupId is a task that should be done for a reference project that volunteers to go through all the hassle with a direct helping hand from some Maven folks. I put together this document when I was trying to pull through the whole groupId change last time: http://maven.apache.org/guides/mini/guide-relocation.html There is never a good time to change the groupId. My view is that we should do it when we move to M2, both as a build tool and as the target repository. Yes, I tried to use this description for a M1 -> M2 situation. In the end Carlos' advice was to ignore all the old versions and simply start with the new M2 releases also to use the new groupId and add for those releases only a relocation POM. That is a much easier way to do it. I'm starting to think that this is the way to go for Commons. Just change the groupId when we release with M2 and don't relocate older versions. The problem with adjusting the old releases is, that the location for the relocation POMs is already occupied by the automatically generated POMs for M2 on the global M2 repo (see http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-logging/commons-logging/1.1/). And since they're already published, they cannot be changed anymore. I think you are allowed to add a relocation section to an already published pom. I vaguely remember discussing this with Carlos back then. [snip] - Jörg -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
VOTE: Release commons-fileupload 1.2 (3rd attempt)
Hi, I have prepared commons-fileupload-1.2rc3. Compared to 1.2rc2, the following changes have been made: - The sources are now available as tar.gz and .zip file. - The build has been made with JDK 1.5.0_11, rather than 1.6.0rc1. Please note, that this release (like all releases) requires, in particular, 3 positive votes from PMC members. Thanks, Jochen [ ] +1 [ ] =0 [ ] -1 -- How fast can a year go? As fast as your childs first year. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r504493 - /jakarta/commons/proper/fileupload/tags/commons-fileupload-1.2rc3/
Author: jochen Date: Wed Feb 7 02:44:34 2007 New Revision: 504493 URL: http://svn.apache.org/viewvc?view=rev&rev=504493 Log: (empty) Added: jakarta/commons/proper/fileupload/tags/commons-fileupload-1.2rc3/ - copied from r504492, jakarta/commons/proper/fileupload/branches/b1_2/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2 (WAS: [VOTE] commons-fileupload 1.2 (rc2))
Henri Yandell wrote: > On 2/5/07, Jörg Schaible <[EMAIL PROTECTED]> wrote: [snip] >> from my personal experience with a different project all I can say is >> that changing the groupId is a task that is not very well supported by >> M2. The available docs are spare, do not work as they are described or >> are out of date. So changing the groupId is a task that should be done >> for a reference project that volunteers to go through all the hassle with >> a direct helping hand from some Maven folks. > > My understanding was that once we started doing m2 builds we would be > changing group ids. What I really mean here is deploying to an m2 > repository rather than doing m2 builds. So if Jochen's plan is to do > an m2 build and send it to the m2 repository, then this point is moot. M2 will publish to the M2 repo. The location is simply defined by the groupId ... whatever it is. We can use commons-xxx as well as org.apache.commons, there's no technical restriction. It is simply our decision. [snip] > We've definitely been shifting in the last few Commons releases to > building the actual 1.2 release and then voting on it, rather than > building releases with -rc2 in the jar name etc. It's just been a > tribal change on the lists currently (Craig kicked off a thread about > it a few months ago). I know, but it is not yet supported by the current (released) tool chain of Maven. [snip] >> Please also ensure, that you build from the labeled source code in >> Subversion. That's the main advantage for me using reelase plugin. > > By labeled, do you mean the svn tag? Yes. [snip] - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2 (WAS: [VOTE] commons-fileupload 1.2 (rc2))
Hi Dennis, Dennis Lundberg wrote: > Henri Yandell wrote: >> On 2/5/07, Jörg Schaible <[EMAIL PROTECTED]> wrote: >>> Hi Jochen, >>> >>> Jochen Wiedmann wrote on Monday, February 05, 2007 9:03 AM: >>> >>> >> I'm thinking: >>> >> >>> >> * Change group id? >>> > >>> > Couldn't we do that *after* the release, please? I would clearly >>> > prefer *not* to introduce any incompatible changes in that stage. >>> >>> +1 >>> >>> from my personal experience with a different project all I can say is >>> that changing the groupId is >>> a task that is not very well supported by M2. The available docs are >>> spare, do not work as they >>> are described or are out of date. So changing the groupId is a task >>> that should be done for a >>> reference project that volunteers to go through all the hassle with a >>> direct helping hand from >>> some Maven folks. > > I put together this document when I was trying to pull through the whole > groupId change last time: > >http://maven.apache.org/guides/mini/guide-relocation.html > > There is never a good time to change the groupId. My view is that we > should do it when we move to M2, both as a build tool and as the target > repository. Yes, I tried to use this description for a M1 -> M2 situation. In the end Carlos' advice was to ignore all the old versions and simply start with the new M2 releases also to use the new groupId and add for those releases only a relocation POM. The problem with adjusting the old releases is, that the location for the relocation POMs is already occupied by the automatically generated POMs for M2 on the global M2 repo (see http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-logging/commons-logging/1.1/). And since they're already published, they cannot be changed anymore. [snip] - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2 (WAS: [VOTE] commons-fileupload 1.2 (rc2))
Henri Yandell wrote: On 2/5/07, Jörg Schaible <[EMAIL PROTECTED]> wrote: Hi Jochen, Jochen Wiedmann wrote on Monday, February 05, 2007 9:03 AM: >> I'm thinking: >> >> * Change group id? > > Couldn't we do that *after* the release, please? I would clearly > prefer *not* to introduce any incompatible changes in that stage. +1 from my personal experience with a different project all I can say is that changing the groupId is a task that is not very well supported by M2. The available docs are spare, do not work as they are described or are out of date. So changing the groupId is a task that should be done for a reference project that volunteers to go through all the hassle with a direct helping hand from some Maven folks. I put together this document when I was trying to pull through the whole groupId change last time: http://maven.apache.org/guides/mini/guide-relocation.html There is never a good time to change the groupId. My view is that we should do it when we move to M2, both as a build tool and as the target repository. My understanding was that once we started doing m2 builds we would be changing group ids. What I really mean here is deploying to an m2 repository rather than doing m2 builds. So if Jochen's plan is to do an m2 build and send it to the m2 repository, then this point is moot. >> * How do we build a 2.0 release and vote on that rather than voting >> on the release manager's ability to do a release? Is there a way to >> deploy known files to an m2 repository rather than having to rebuild? > > I never intended to publish the exact distributables that we voted on. > For example, I never intented to change version numbers within the > binary distributables from 1.2rc2 to 1.2. How do others do that? This seems currently a process in flux. It seems clear that the standard functionality of M 2.0.4 & released plugins does not match the necessary steps for Apache releases. M2 folks have developed and improved some plugins now that support signing and staging, but nothing is released yet. In the mean time you either live with it or you'll process some manual steps. Releases have been made, but not yet for all the plugins that take part in the release process. It is very close though. Which again is really about whether we goto an m2 repository than anything else. We've definitely been shifting in the last few Commons releases to building the actual 1.2 release and then voting on it, rather than building releases with -rc2 in the jar name etc. It's just been a tribal change on the lists currently (Craig kicked off a thread about it a few months ago). > Afar from that, I never intended to use the release manager. To be > honest, I never got it working. What's the problem here? I use it all the time (although never for an Apache release yet). > I was thinking along the lines of > > mvn -Drelease clean install site assembly:assembly deploy > > Which is (apart from the "deploy") exactly what I did to build the > current files. Please also ensure, that you build from the labeled source code in Subversion. That's the main advantage for me using reelase plugin. By labeled, do you mean the svn tag? > If you insist, I can omit the "deploy" and do the deployment manually. > (In other words, omit rebuilding the files.) That said, I spent a lot > of time in an automatic build exactly for *not* requiring any manual > interventions, because I trust my build system more than myself. > > >> * How much of the release code can be shared - I can see stuff in the >> pom.xml, can that stuff be in the parent pom? > > Yes, but my clear intention was *not* to wait for a release of > commons-parent again (I already did so last year for several months), > rather than learning from this release and then move the stuff up > later. (Note, that I did all changes in a branch, to allow me for > careful integration into either trunk or commons-parent later.) +1 there's always room for improvement and we should rather use a project's POM to introduce new parts to a build then to add all stuff immediately to the parent. If the release went fine and the extension has shown to be useful, we might propagate the improvement to the parent *afterwards*. Sounds fine. The m2 versioning of parents does mean that even if you do something that is later considered the wrong direction when things are put in -parent, it won't hurt users very much. +1 Hen -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] commons-fileupload 1.2 (rc2)
Also - the build is built using 1.6.0-rc with source/binary flags set for 1.3. I'm happy to do that and let the user report if they find they can't use it on 1.3+, but others seem to care strongly so just reporting it. Is 1.6.0-rc the released version or one of the betas? Not sure what Sun's naming convention is there. Hen On 2/5/07, Henri Yandell <[EMAIL PROTECTED]> wrote: On 2/5/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: > On 2/5/07, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > * No zip file for the -src. > > Ok, added zip file generation to the source assembly. > > > * The tar.gz doesn't open into *-src/ directory. > > That wasn't the case for the previous fileupload releases. Why change it? No idea - other components do etc. Well, I say no idea - I think generally because it's a pattern for foo.tgz to unpack into foo and bar.zip to unpack into bar. And so that the binary and src archives can unpack next to each other. > > * Unable to find your key so I can verify the pgp. > > See, for example, > > http://www.apache.org/dist/ws/jaxme/KEYS > http://www.apache.org/dist/ws/xmlrpc/KEYS > > You are right, of course, that an entry must be added to the KEYS file. > > > > Jars were built by Plexus, so does that mean this is a Maven2 release? > > Yes. > > > > Do we have a plan for how we'll do that? > > What's the deal? Just a radar thing - Maven2 releases (using the release manager) have flagged for me as something that could make changes on our release process so my radar is beeping. I'll reply to the Maven 2 thread that's been started. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2 (WAS: [VOTE] commons-fileupload 1.2 (rc2))
On 2/5/07, Jörg Schaible <[EMAIL PROTECTED]> wrote: Hi Jochen, Jochen Wiedmann wrote on Monday, February 05, 2007 9:03 AM: >> I'm thinking: >> >> * Change group id? > > Couldn't we do that *after* the release, please? I would clearly > prefer *not* to introduce any incompatible changes in that stage. +1 from my personal experience with a different project all I can say is that changing the groupId is a task that is not very well supported by M2. The available docs are spare, do not work as they are described or are out of date. So changing the groupId is a task that should be done for a reference project that volunteers to go through all the hassle with a direct helping hand from some Maven folks. My understanding was that once we started doing m2 builds we would be changing group ids. What I really mean here is deploying to an m2 repository rather than doing m2 builds. So if Jochen's plan is to do an m2 build and send it to the m2 repository, then this point is moot. >> * How do we build a 2.0 release and vote on that rather than voting >> on the release manager's ability to do a release? Is there a way to >> deploy known files to an m2 repository rather than having to rebuild? > > I never intended to publish the exact distributables that we voted on. > For example, I never intented to change version numbers within the > binary distributables from 1.2rc2 to 1.2. How do others do that? This seems currently a process in flux. It seems clear that the standard functionality of M 2.0.4 & released plugins does not match the necessary steps for Apache releases. M2 folks have developed and improved some plugins now that support signing and staging, but nothing is released yet. In the mean time you either live with it or you'll process some manual steps. Which again is really about whether we goto an m2 repository than anything else. We've definitely been shifting in the last few Commons releases to building the actual 1.2 release and then voting on it, rather than building releases with -rc2 in the jar name etc. It's just been a tribal change on the lists currently (Craig kicked off a thread about it a few months ago). > Afar from that, I never intended to use the release manager. To be > honest, I never got it working. What's the problem here? I use it all the time (although never for an Apache release yet). > I was thinking along the lines of > > mvn -Drelease clean install site assembly:assembly deploy > > Which is (apart from the "deploy") exactly what I did to build the > current files. Please also ensure, that you build from the labeled source code in Subversion. That's the main advantage for me using reelase plugin. By labeled, do you mean the svn tag? > If you insist, I can omit the "deploy" and do the deployment manually. > (In other words, omit rebuilding the files.) That said, I spent a lot > of time in an automatic build exactly for *not* requiring any manual > interventions, because I trust my build system more than myself. > > >> * How much of the release code can be shared - I can see stuff in the >> pom.xml, can that stuff be in the parent pom? > > Yes, but my clear intention was *not* to wait for a release of > commons-parent again (I already did so last year for several months), > rather than learning from this release and then move the stuff up > later. (Note, that I did all changes in a branch, to allow me for > careful integration into either trunk or commons-parent later.) +1 there's always room for improvement and we should rather use a project's POM to introduce new parts to a build then to add all stuff immediately to the parent. If the release went fine and the extension has shown to be useful, we might propagate the improvement to the parent *afterwards*. Sounds fine. The m2 versioning of parents does mean that even if you do something that is later considered the wrong direction when things are put in -parent, it won't hurt users very much. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] commons-fileupload 1.2 (rc2)
On 2/5/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: On 2/5/07, Henri Yandell <[EMAIL PROTECTED]> wrote: > * No zip file for the -src. Ok, added zip file generation to the source assembly. > * The tar.gz doesn't open into *-src/ directory. That wasn't the case for the previous fileupload releases. Why change it? No idea - other components do etc. Well, I say no idea - I think generally because it's a pattern for foo.tgz to unpack into foo and bar.zip to unpack into bar. And so that the binary and src archives can unpack next to each other. > * Unable to find your key so I can verify the pgp. See, for example, http://www.apache.org/dist/ws/jaxme/KEYS http://www.apache.org/dist/ws/xmlrpc/KEYS You are right, of course, that an entry must be added to the KEYS file. > Jars were built by Plexus, so does that mean this is a Maven2 release? Yes. > Do we have a plan for how we'll do that? What's the deal? Just a radar thing - Maven2 releases (using the release manager) have flagged for me as something that could make changes on our release process so my radar is beeping. I'll reply to the Maven 2 thread that's been started. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven 2 (WAS: [VOTE] commons-fileupload 1.2 (rc2))
Hi Jochen, Jochen Wiedmann wrote on Monday, February 05, 2007 9:03 AM: >> I'm thinking: >> >> * Change group id? > > Couldn't we do that *after* the release, please? I would clearly > prefer *not* to introduce any incompatible changes in that stage. +1 from my personal experience with a different project all I can say is that changing the groupId is a task that is not very well supported by M2. The available docs are spare, do not work as they are described or are out of date. So changing the groupId is a task that should be done for a reference project that volunteers to go through all the hassle with a direct helping hand from some Maven folks. >> * How do we build a 2.0 release and vote on that rather than voting >> on the release manager's ability to do a release? Is there a way to >> deploy known files to an m2 repository rather than having to rebuild? > > I never intended to publish the exact distributables that we voted on. > For example, I never intented to change version numbers within the > binary distributables from 1.2rc2 to 1.2. How do others do that? This seems currently a process in flux. It seems clear that the standard functionality of M 2.0.4 & released plugins does not match the necessary steps for Apache releases. M2 folks have developed and improved some plugins now that support signing and staging, but nothing is released yet. In the mean time you either live with it or you'll process some manual steps. > Afar from that, I never intended to use the release manager. To be > honest, I never got it working. What's the problem here? I use it all the time (although never for an Apache release yet). > I was thinking along the lines of > > mvn -Drelease clean install site assembly:assembly deploy > > Which is (apart from the "deploy") exactly what I did to build the > current files. Please also ensure, that you build from the labeled source code in Subversion. That's the main advantage for me using reelase plugin. > If you insist, I can omit the "deploy" and do the deployment manually. > (In other words, omit rebuilding the files.) That said, I spent a lot > of time in an automatic build exactly for *not* requiring any manual > interventions, because I trust my build system more than myself. > > >> * How much of the release code can be shared - I can see stuff in the >> pom.xml, can that stuff be in the parent pom? > > Yes, but my clear intention was *not* to wait for a release of > commons-parent again (I already did so last year for several months), > rather than learning from this release and then move the stuff up > later. (Note, that I did all changes in a branch, to allow me for > careful integration into either trunk or commons-parent later.) +1 there's always room for improvement and we should rather use a project's POM to introduce new parts to a build then to add all stuff immediately to the parent. If the release went fine and the extension has shown to be useful, we might propagate the improvement to the parent *afterwards*. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] commons-fileupload 1.2 (rc2)
On 2/5/07, Henri Yandell <[EMAIL PROTECTED]> wrote: * No zip file for the -src. Ok, added zip file generation to the source assembly. * The tar.gz doesn't open into *-src/ directory. That wasn't the case for the previous fileupload releases. Why change it? * Unable to find your key so I can verify the pgp. See, for example, http://www.apache.org/dist/ws/jaxme/KEYS http://www.apache.org/dist/ws/xmlrpc/KEYS You are right, of course, that an entry must be added to the KEYS file. Jars were built by Plexus, so does that mean this is a Maven2 release? Yes. Do we have a plan for how we'll do that? What's the deal? I'm thinking: * Change group id? Couldn't we do that *after* the release, please? I would clearly prefer *not* to introduce any incompatible changes in that stage. * How do we build a 2.0 release and vote on that rather than voting on the release manager's ability to do a release? Is there a way to deploy known files to an m2 repository rather than having to rebuild? I never intended to publish the exact distributables that we voted on. For example, I never intented to change version numbers within the binary distributables from 1.2rc2 to 1.2. How do others do that? Afar from that, I never intended to use the release manager. To be honest, I never got it working. I was thinking along the lines of mvn -Drelease clean install site assembly:assembly deploy Which is (apart from the "deploy") exactly what I did to build the current files. If you insist, I can omit the "deploy" and do the deployment manually. (In other words, omit rebuilding the files.) That said, I spent a lot of time in an automatic build exactly for *not* requiring any manual interventions, because I trust my build system more than myself. * How much of the release code can be shared - I can see stuff in the pom.xml, can that stuff be in the parent pom? Yes, but my clear intention was *not* to wait for a release of commons-parent again (I already did so last year for several months), rather than learning from this release and then move the stuff up later. (Note, that I did all changes in a branch, to allow me for careful integration into either trunk or commons-parent later.) Jochen -- How fast can a year go? As fast as your childs first year. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] commons-fileupload 1.2 (rc2)
* No zip file for the -src. * The tar.gz doesn't open into *-src/ directory. * Unable to find your key so I can verify the pgp. -- MD5s good. Ant, Maven and Maven2 all work from the src tar.gz. Jars were built by Plexus, so does that mean this is a Maven2 release? Do we have a plan for how we'll do that? I'm thinking: * Change group id? * How do we build a 2.0 release and vote on that rather than voting on the release manager's ability to do a release? Is there a way to deploy known files to an m2 repository rather than having to rebuild? * How much of the release code can be shared - I can see stuff in the pom.xml, can that stuff be in the parent pom? Hen On 2/1/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: Hi, after IO 1.3 is out, I've made a second release candidate available for review on http://people.apache.org/~jochen/commons-fileupload/dist The proposed site can be viewed at http://people.apache.org/~jochen/commons-fileupload/site The site includes clirr and checkstyle reports, a rat report is at http://people.apache.org/~jochen/commons-fileupload/dist/rat.txt (This report was created by using the rat-maven-plugin, btw.) Please cast your vote: [ ] +1 [ ] =0 [ ] -1 I'll keep the vote open until saturday, if noone else intervenes. Jochen -- How fast can a year go? As fast as your childs first year. - 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: r502368 - /jakarta/commons/proper/fileupload/tags/commons-fileupload-1.2rc2/
Author: jochen Date: Thu Feb 1 13:53:11 2007 New Revision: 502368 URL: http://svn.apache.org/viewvc?view=rev&rev=502368 Log: (empty) Added: jakarta/commons/proper/fileupload/tags/commons-fileupload-1.2rc2/ - copied from r502367, jakarta/commons/proper/fileupload/branches/b1_2/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] commons-fileupload 1.2 (rc2)
Hi, after IO 1.3 is out, I've made a second release candidate available for review on http://people.apache.org/~jochen/commons-fileupload/dist The proposed site can be viewed at http://people.apache.org/~jochen/commons-fileupload/site The site includes clirr and checkstyle reports, a rat report is at http://people.apache.org/~jochen/commons-fileupload/dist/rat.txt (This report was created by using the rat-maven-plugin, btw.) Please cast your vote: [ ] +1 [ ] =0 [ ] -1 I'll keep the vote open until saturday, if noone else intervenes. Jochen -- How fast can a year go? As fast as your childs first year. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r502350 - in /jakarta/commons/proper/fileupload/branches/b1_2/src/java/org/apache/commons/fileupload: FileUploadBase.java MultipartStream.java disk/DiskFileItemFactory.java servlet/FileCle
Author: jochen
Date: Thu Feb 1 12:42:48 2007
New Revision: 502350
URL: http://svn.apache.org/viewvc?view=rev&rev=502350
Log:
Making checkstyle and clirr happy.
Modified:
jakarta/commons/proper/fileupload/branches/b1_2/src/java/org/apache/commons/fileupload/FileUploadBase.java
jakarta/commons/proper/fileupload/branches/b1_2/src/java/org/apache/commons/fileupload/MultipartStream.java
jakarta/commons/proper/fileupload/branches/b1_2/src/java/org/apache/commons/fileupload/disk/DiskFileItemFactory.java
jakarta/commons/proper/fileupload/branches/b1_2/src/java/org/apache/commons/fileupload/servlet/FileCleanerCleanup.java
Modified:
jakarta/commons/proper/fileupload/branches/b1_2/src/java/org/apache/commons/fileupload/FileUploadBase.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/branches/b1_2/src/java/org/apache/commons/fileupload/FileUploadBase.java?view=diff&rev=502350&r1=502349&r2=502350
==
---
jakarta/commons/proper/fileupload/branches/b1_2/src/java/org/apache/commons/fileupload/FileUploadBase.java
(original)
+++
jakarta/commons/proper/fileupload/branches/b1_2/src/java/org/apache/commons/fileupload/FileUploadBase.java
Thu Feb 1 12:42:48 2007
@@ -158,7 +158,7 @@
*/
public static final int MAX_HEADER_SIZE = 1024;
-
+
// --- Data members
@@ -342,7 +342,8 @@
List items = new ArrayList();
FileItemFactory fac = getFileItemFactory();
if (fac == null) {
-throw new NullPointerException("No FileItemFactory has been
set.");
+throw new NullPointerException(
+"No FileItemFactory has been set.");
}
while (iter.hasNext()) {
FileItemStream item = iter.next();
@@ -485,7 +486,7 @@
getFileName(headers));
}
-
+
/**
* Parses the header-part and returns as key/value
* pairs.
@@ -1114,14 +1115,17 @@
private static final long serialVersionUID = -2474893167098052828L;
/**
- * @deprecated Replaced by [EMAIL PROTECTED]
#SizeLimitExceededException(String, long, long)}
+ * @deprecated Replaced by
+ * [EMAIL PROTECTED] #SizeLimitExceededException(String, long, long)}
*/
public SizeLimitExceededException() {
this(null, 0, 0);
}
/**
- * @deprecated Replaced by [EMAIL PROTECTED]
#SizeLimitExceededException(String, long, long)}
+ * @deprecated Replaced by
+ * [EMAIL PROTECTED] #SizeLimitExceededException(String, long, long)}
+ * @param message The exceptions detail message.
*/
public SizeLimitExceededException(String message) {
this(message, 0, 0);
Modified:
jakarta/commons/proper/fileupload/branches/b1_2/src/java/org/apache/commons/fileupload/MultipartStream.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/branches/b1_2/src/java/org/apache/commons/fileupload/MultipartStream.java?view=diff&rev=502350&r1=502349&r2=502350
==
---
jakarta/commons/proper/fileupload/branches/b1_2/src/java/org/apache/commons/fileupload/MultipartStream.java
(original)
+++
jakarta/commons/proper/fileupload/branches/b1_2/src/java/org/apache/commons/fileupload/MultipartStream.java
Thu Feb 1 12:42:48 2007
@@ -278,6 +278,38 @@
// --- Constructors
+/**
+ * Creates a new instance.
+ * @deprecated Use [EMAIL PROTECTED] #MultipartStream(InputStream, byte[],
+ * org.apache.commons.fileupload.MultipartStream.ProgressNotifier)},
+ * or [EMAIL PROTECTED] #MultipartStream(InputStream, byte[], int,
+ * org.apache.commons.fileupload.MultipartStream.ProgressNotifier)}
+ */
+public MultipartStream() {
+this(null, null, null);
+}
+
+/**
+ * Constructs a MultipartStream with a custom size buffer
+ * and no progress notifier.
+ *
+ * Note that the buffer must be at least big enough to contain the
+ * boundary string, plus 4 characters for CR/LF and double dash, plus at
+ * least one byte of data. Too small a buffer size setting will degrade
+ * performance.
+ *
+ * @param inputThe InputStream to serve as a data source.
+ * @param boundary The token used for dividing the stream into
+ * encapsulations.
+ * @param bufSize The size of the buffer to be used, in bytes.
+ *
+ * @see #MultipartStream(InputStream, byte[], ProgressNotifier)
+ * @deprecated Use [EMAIL PROTECTED] #MultipartStream(InputStream, byte[],
int,
+ * org.apache.commons.fileupload.MultipartStream.ProgressNotifier)}.
+
svn commit: r494610 - in /jakarta/commons/proper/fileupload/trunk/src: changes/changes.xml java/org/apache/commons/fileupload/FileUploadBase.java
Author: jochen
Date: Tue Jan 9 13:53:55 2007
New Revision: 494610
URL: http://svn.apache.org/viewvc?view=rev&rev=494610
Log:
A descriptive NPE is now thrown, if the FileItemFactory hasn't been set.
PR: FILEUPLOAD-123
Modified:
jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadBase.java
Modified: jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml?view=diff&rev=494610&r1=494609&r2=494610
==
--- jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml (original)
+++ jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml Tue Jan 9
13:53:55 2007
@@ -88,6 +88,11 @@
Added the FileCleanerCleanup as an example for how to close
down the FileCleaner's reaper thread nicely.
+
+
+A descriptive NPE is now thrown, if the FileItemFactory
+has not been set.
+
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadBase.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadBase.java?view=diff&rev=494610&r1=494609&r2=494610
==
---
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadBase.java
(original)
+++
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadBase.java
Tue Jan 9 13:53:55 2007
@@ -341,6 +341,9 @@
FileItemIterator iter = getItemIterator(ctx);
List items = new ArrayList();
FileItemFactory fac = getFileItemFactory();
+if (fac == null) {
+throw new NullPointerException("No FileItemFactory has been
set.");
+}
while (iter.hasNext()) {
FileItemStream item = iter.next();
FileItem fileItem = fac.createItem(item.getFieldName(),
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r485503 - /jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/servlet/FileCleanerCleanup.java
Author: martinc Date: Sun Dec 10 20:55:24 2006 New Revision: 485503 URL: http://svn.apache.org/viewvc?view=rev&rev=485503 Log: Fix SVN properties for newly added file. Modified: jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/servlet/FileCleanerCleanup.java (props changed) Propchange: jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/servlet/FileCleanerCleanup.java -- svn:eol-style = native Propchange: jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/servlet/FileCleanerCleanup.java -- svn:keywords = Date Author Id Revision HeadURL - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project commons-fileupload (in module jakarta-commons) failed
On 12/8/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: jakarta-servletapi is Servlet 2.2 but its been fixed already - although they've bumped the gump descriptor from servlet 2.2 to servlet 2.4: http://tinyurl.com/ymq8p6 Fine with me. Better gump using the more recent version than the pom's. :-) Thanks, Jochen -- My wife Mary and I have been married for forty-seven years and not once have we had an argument serious enough to consider divorce; murder, yes, but divorce, never. (Jack Benny) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project commons-fileupload (in module jakarta-commons) failed
On 12/8/06, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: Hi, can anyone help me here? I have no idea what might be the problem. The error message seems to indicate that the ServletContextListener class is unknown. This class is available in the Servlet API since 2.3, which is the version in project.xml and pom.xml. The gump descriptor only mentions "servletapi", but I would assume that this isn't 2.2 or before, or am I wrong? If so, what is the correct setting? jakarta-servletapi is Servlet 2.2 but its been fixed already - although they've bumped the gump descriptor from servlet 2.2 to servlet 2.4: http://tinyurl.com/ymq8p6 Niall Thanks, Jochen On 12/7/06, John McNally <[EMAIL PROTECTED]> wrote: > [javac] /x1/gump/public/workspace/jakarta-commons/fileupload/src/java/org/apache/commons/fileupload/servlet/FileCleanerCleanup.java:19: cannot find symbol > [javac] symbol : class ServletContextListener > [javac] location: package javax.servlet > [javac] import javax.servlet.ServletContextListener; > [javac] ^ > [javac] /x1/gump/public/workspace/jakarta-commons/fileupload/src/java/org/apache/commons/fileupload/servlet/FileCleanerCleanup.java:20: cannot find symbol - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project commons-fileupload (in module jakarta-commons) failed
Hi, can anyone help me here? I have no idea what might be the problem. The error message seems to indicate that the ServletContextListener class is unknown. This class is available in the Servlet API since 2.3, which is the version in project.xml and pom.xml. The gump descriptor only mentions "servletapi", but I would assume that this isn't 2.2 or before, or am I wrong? If so, what is the correct setting? Thanks, Jochen On 12/7/06, John McNally <[EMAIL PROTECTED]> wrote: [javac] /x1/gump/public/workspace/jakarta-commons/fileupload/src/java/org/apache/commons/fileupload/servlet/FileCleanerCleanup.java:19: cannot find symbol [javac] symbol : class ServletContextListener [javac] location: package javax.servlet [javac] import javax.servlet.ServletContextListener; [javac] ^ [javac] /x1/gump/public/workspace/jakarta-commons/fileupload/src/java/org/apache/commons/fileupload/servlet/FileCleanerCleanup.java:20: cannot find symbol -- My wife Mary and I have been married for forty-seven years and not once have we had an argument serious enough to consider divorce; murder, yes, but divorce, never. (Jack Benny) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-fileupload (in module jakarta-commons) 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-fileupload has an issue affecting its community integration. This issue affects 20 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-fileupload : Commons File Upload Package - fulcrum-intake : Services Framework - fulcrum-parser : Services Framework - fulcrum-upload : Services Framework - jakarta-cactus-documentation : Cactus Documentation - jakarta-cactus-release-12 : Unit test framework for server-side java code - jakarta-cactus-release-13 : Unit test framework for server-side java code - jakarta-cactus-sample-jetty-13 : Cactus Jetty Sample (J2EE 1.3) - jakarta-cactus-sample-servlet-13 : Cactus Servlet Sample (J2EE 1.3) - jakarta-slide : Content Management System based on WebDAV technology - jakarta-tomcat-4.0 : Servlet 2.3 and JSP 1.2 Reference Implementation - jakarta-tomcat-catalina : Servlet 2.4 Reference Implementation - jakarta-tomcat-coyote-tomcat4 : Connectors to various web servers - jakarta-tomcat-jk : Connectors to various web servers - jakarta-turbine-2 : A servlet based framework. - myfaces : JavaServer(tm) Faces implementation - portals-bridges-jsf : Support for JSR168 compliant Portlet development - portals-jetspeed-1 : Enterprise Information Portal - portals-pluto-portal-1.0 : JSR168 Container - tomcat-catalina : Servlet 2.3 and JSP 1.2 Reference Implementation Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-fileupload/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-fileupload-06122006.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons/commons-fileupload/gump_work/build_jakarta-commons_commons-fileupload.html Work Name: build_jakarta-commons_commons-fileupload (Type: Build) Work ended in a state of : Failed Elapsed: 3 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dmaven.final.name=commons-fileupload-06122006 -f build-gump.xml jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/fileupload] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/fileupload/target/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar:/usr/local/gump/public/workspace/portals-pluto-1.0/api/target/portlet-api-1.0.jar:/usr/local/gump/public/workspace/jakarta-commons/io/build/jakarta-commons-io-06122006.jar - Buildfile: build-gump.xml jar: [mkdir] Created dir: /x1/gump/public/workspace/jakarta-commons/fileupload/target/classes [javac] Compiling 24 source files to /x1/gump/public/workspace/jakarta-commons/fileupload/target/classes [javac] /x1/gump/public/workspace/jakarta-commons/fileupload/src/java/org/apache/commons/fileupload/servlet/FileCleanerCleanup.java:19: cannot find symbol [javac] symbol : class ServletContextListener [javac] location: package javax.servlet [javac] import javax.servlet.ServletContextListener; [javac] ^ [javac] /x1/gump/public/workspace/jakarta-commons/fileupload/src/java/org/apache/commons/fileupload/servlet/FileCleanerCleanup.java:20: cannot find symbol [javac] symbol : class ServletContextEvent [javac] location: package javax.servlet [javac] import javax.servlet.ServletContextEvent; [javac] ^ [javac] /x1/g
[EMAIL PROTECTED]: Project commons-fileupload (in module jakarta-commons) 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-fileupload has an issue affecting its community integration. This issue affects 20 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-fileupload : Commons File Upload Package - fulcrum-intake : Services Framework - fulcrum-parser : Services Framework - fulcrum-upload : Services Framework - jakarta-cactus-documentation : Cactus Documentation - jakarta-cactus-release-12 : Unit test framework for server-side java code - jakarta-cactus-release-13 : Unit test framework for server-side java code - jakarta-cactus-sample-jetty-13 : Cactus Jetty Sample (J2EE 1.3) - jakarta-cactus-sample-servlet-13 : Cactus Servlet Sample (J2EE 1.3) - jakarta-slide : Content Management System based on WebDAV technology - jakarta-tomcat-4.0 : Servlet 2.3 and JSP 1.2 Reference Implementation - jakarta-tomcat-catalina : Servlet 2.4 Reference Implementation - jakarta-tomcat-coyote-tomcat4 : Connectors to various web servers - jakarta-tomcat-jk : Connectors to various web servers - jakarta-turbine-2 : A servlet based framework. - myfaces : JavaServer(tm) Faces implementation - portals-bridges-jsf : Support for JSR168 compliant Portlet development - portals-jetspeed-1 : Enterprise Information Portal - portals-pluto-portal-1.0 : JSR168 Container - tomcat-catalina : Servlet 2.3 and JSP 1.2 Reference Implementation Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-fileupload/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-fileupload-06122006.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons/commons-fileupload/gump_work/build_jakarta-commons_commons-fileupload.html Work Name: build_jakarta-commons_commons-fileupload (Type: Build) Work ended in a state of : Failed Elapsed: 3 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dmaven.final.name=commons-fileupload-06122006 -f build-gump.xml jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/fileupload] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/fileupload/target/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar:/usr/local/gump/public/workspace/portals-pluto-1.0/api/target/portlet-api-1.0.jar:/usr/local/gump/public/workspace/jakarta-commons/io/build/jakarta-commons-io-06122006.jar - Buildfile: build-gump.xml jar: [mkdir] Created dir: /x1/gump/public/workspace/jakarta-commons/fileupload/target/classes [javac] Compiling 24 source files to /x1/gump/public/workspace/jakarta-commons/fileupload/target/classes [javac] /x1/gump/public/workspace/jakarta-commons/fileupload/src/java/org/apache/commons/fileupload/servlet/FileCleanerCleanup.java:19: cannot find symbol [javac] symbol : class ServletContextListener [javac] location: package javax.servlet [javac] import javax.servlet.ServletContextListener; [javac] ^ [javac] /x1/gump/public/workspace/jakarta-commons/fileupload/src/java/org/apache/commons/fileupload/servlet/FileCleanerCleanup.java:20: cannot find symbol [javac] symbol : class ServletContextEvent [javac] location: package javax.servlet [javac] import javax.servlet.ServletContextEvent; [javac] ^ [javac] /x1/g
svn commit: r482993 - in /jakarta/commons/proper/fileupload/trunk: ./ src/changes/ src/java/org/apache/commons/fileupload/disk/ src/java/org/apache/commons/fileupload/servlet/ xdocs/
Author: jochen Date: Wed Dec 6 01:42:01 2006 New Revision: 482993 URL: http://svn.apache.org/viewvc?view=rev&rev=482993 Log: Added the FileCleanerCleanup and docs on how to use it. Submitted-By: Henry Yandell, [EMAIL PROTECTED] PR: FILEUPLOAD-120 Added: jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/servlet/FileCleanerCleanup.java Modified: jakarta/commons/proper/fileupload/trunk/pom.xml jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItemFactory.java jakarta/commons/proper/fileupload/trunk/xdocs/using.xml Modified: jakarta/commons/proper/fileupload/trunk/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/pom.xml?view=diff&rev=482993&r1=482992&r2=482993 == --- jakarta/commons/proper/fileupload/trunk/pom.xml (original) +++ jakarta/commons/proper/fileupload/trunk/pom.xml Wed Dec 6 01:42:01 2006 @@ -100,6 +100,10 @@ Amichai Rothman [EMAIL PROTECTED] + + Henry Yandell + [EMAIL PROTECTED] + @@ -175,9 +179,9 @@ provided - commons-io + org.apache.commons commons-io - 1.1 + 1.3-SNAPSHOT true Modified: jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml?view=diff&rev=482993&r1=482992&r2=482993 == --- jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml (original) +++ jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml Wed Dec 6 01:42:01 2006 @@ -82,6 +82,12 @@ It is now possible to limit the actual file size and not the request size. + + +Added the FileCleanerCleanup as an example for how to close +down the FileCleaner's reaper thread nicely. + Modified: jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java?view=diff&rev=482993&r1=482992&r2=482993 == --- jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java (original) +++ jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java Wed Dec 6 01:42:01 2006 @@ -51,6 +51,16 @@ * [EMAIL PROTECTED] #getInputStream()} and process the file without attempting to load * it into memory, which may come handy with large files. * + * When using the DiskFileItemFactory, then you should + * consider the following: Temporary files are automatically deleted as + * soon as they are no longer needed. (More precisely, when the + * corresponding instance of [EMAIL PROTECTED] java.io.File} is garbage collected.) + * This is done by the so-called reaper thread, which is started + * automatically when the class [EMAIL PROTECTED] FileCleaner} is loaded. + * It might make sense to terminate that thread, for example, if + * your web application ends. See the section on "Resource cleanup" + * in the users guide of commons-fileupload. + * * @author mailto:[EMAIL PROTECTED]">Rafal Krzewski * @author mailto:[EMAIL PROTECTED]">Sean Legassick * @author mailto:[EMAIL PROTECTED]">Jason van Zyl Modified: jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItemFactory.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItemFactory.java?view=diff&rev=482993&r1=482992&r2=482993 ========== --- jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItemFactory.java (original) +++ jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItemFactory.java Wed Dec 6 01:42:01 2006 @@ -20,6 +20,7 @@ import org.apache.commons.fileupload.FileItem; import org.apache.commons.fileupload.FileItemFactory; +import org.apache.commons.io.FileCleaner; /** * The default [EMAIL PROTECTED] org.apache.commons.fileupload.FileItemFactory} @@ -39,6 +40,16 @@ * * * + * When using the DiskFileItemFactory, then you should + * consider the following: Temporary files are automatically deleted as + * soon as they are no longer needed.
svn commit: r480449 - /jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java
Author: jochen
Date: Tue Nov 28 23:43:08 2006
New Revision: 480449
URL: http://svn.apache.org/viewvc?view=rev&rev=480449
Log:
Avoid duplicating local field names and unnecessary else.
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java?view=diff&rev=480449&r1=480448&r2=480449
==
---
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java
(original)
+++
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java
Tue Nov 28 23:43:08 2006
@@ -262,9 +262,8 @@
public boolean isInMemory() {
if (cachedContent != null) {
return true;
-} else {
-return dfos.isInMemory();
}
+return dfos.isInMemory();
}
@@ -585,9 +584,9 @@
tempDir = new File(System.getProperty("java.io.tmpdir"));
}
-String fileName = "upload_" + UID + "_" + getUniqueId() + ".tmp";
+String tempFileName = "upload_" + UID + "_" + getUniqueId() + ".tmp";
-File f = new File(tempDir, fileName);
+File f = new File(tempDir, tempFileName);
FileCleaner.track(f, this);
return f;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r479935 - in /jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload: FileUploadBase.java MultipartStream.java
Author: jochen
Date: Mon Nov 27 23:40:07 2006
New Revision: 479935
URL: http://svn.apache.org/viewvc?view=rev&rev=479935
Log:
Restored the ability of commons-fileupload 1.2, to act as a
drop-in replacement for 1.1. (Note: The semantical changes
between 1.1 and 1.2 do still apply. We only hide them now
and do no longer force the user to notice. :-(
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadBase.java
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadBase.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadBase.java?view=diff&rev=479935&r1=479934&r2=479935
==
---
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadBase.java
(original)
+++
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileUploadBase.java
Mon Nov 27 23:40:07 2006
@@ -149,6 +149,16 @@
public static final String MULTIPART_MIXED = "multipart/mixed";
+/**
+ * The maximum length of a single header line that will be parsed
+ * (1024 bytes).
+ * @deprecated This constant is no longer used. As of commons-fileupload
+ * 1.2, the only applicable limit is the total size of a parts headers,
+ * [EMAIL PROTECTED] MultipartStream#HEADER_PART_SIZE_MAX}.
+ */
+public static final int MAX_HEADER_SIZE = 1024;
+
+
// --- Data members
@@ -450,6 +460,30 @@
/**
+ * Creates a new [EMAIL PROTECTED] FileItem} instance.
+ *
+ * @param headers A Map containing the HTTP request
+ * headers.
+ * @param isFormField Whether or not this item is a form field, as
+ * opposed to a file.
+ *
+ * @return A newly created FileItem instance.
+ *
+ * @throws FileUploadException if an error occurs.
+ * @deprecated This method is no longer used in favour of
+ * internally created instances of [EMAIL PROTECTED] FileItem}.
+ */
+protected FileItem createItem(Map /* String, String */ headers,
+ boolean isFormField)
+throws FileUploadException {
+return getFileItemFactory().createItem(getFieldName(headers),
+getHeader(headers, CONTENT_TYPE),
+isFormField,
+getFileName(headers));
+}
+
+
+/**
* Parses the header-part and returns as key/value
* pairs.
*
@@ -1036,6 +1070,38 @@
}
/**
+ * Thrown to indicate that the request size is not specified. In other
+ * words, it is thrown, if the content-length header is missing or
+ * contains the value -1.
+ * @deprecated As of commons-fileupload 1.2, the presence of a
+ * content-length header is no longer required.
+ */
+public static class UnknownSizeException
+extends FileUploadException {
+/** The exceptions UID, for serializing an instance.
+ */
+private static final long serialVersionUID = 7062279004812015273L;
+
+/**
+ * Constructs a UnknownSizeException with no
+ * detail message.
+ */
+public UnknownSizeException() {
+super();
+}
+
+/**
+ * Constructs an UnknownSizeException with
+ * the specified detail message.
+ *
+ * @param message The detail message.
+ */
+public UnknownSizeException(String message) {
+super(message);
+}
+}
+
+/**
* Thrown to indicate that the request size exceeds the configured maximum.
*/
public static class SizeLimitExceededException
@@ -1043,6 +1109,20 @@
/** The exceptions UID, for serializing an instance.
*/
private static final long serialVersionUID = -2474893167098052828L;
+
+/**
+ * @deprecated Replaced by [EMAIL PROTECTED]
#SizeLimitExceededException(String, long, long)}
+ */
+public SizeLimitExceededException() {
+this(null, 0, 0);
+}
+
+/**
+ * @deprecated Replaced by [EMAIL PROTECTED]
#SizeLimitExceededException(String, long, long)}
+ */
+public SizeLimitExceededException(String message) {
+this(message, 0, 0);
+}
/**
* Constructs a SizeExceededException with
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java?view=di
Re: VOTE: Release commons-fileupload 1.2
Henri Yandell wrote: On 11/26/06, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: Hi, Niall, On 11/26/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: > I would have preferred the release be cut using maven1 rather than m2. > The maven1 build is tried and tested and the gripes of those of us > that checked out previous releases have been fixed in the maven1 > build. I guess that doesn't matter if the release is up to scratch but > would be interested to know if others think we're ready for releases > using m2 yet? See for example http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=115714503628112&w=2 http://marc.theaimsgroup.com/?t=11571905414 In those threads Phil points out that the Maven-2 sites need to look the same as the current Commons sites. There are a couple of sandbox components using Maven-2 sites as a test - csv is one; but the css isn't right yet. Dennis (I think) talked about needing a commons skin for Maven-2. Yep, that's correct. The component sites generated by Maven 2 is not yet up to par with the one's done by Maven 1. In my opinion more work is needed before we can use Maven 2 to generate and publish our sites. Setting up a commons-skin is the "right way" to go, but I have so far been unsuccessful in creating one. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Release commons-fileupload 1.2
On 11/26/06, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: Hi, Niall, On 11/26/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: > I would have preferred the release be cut using maven1 rather than m2. > The maven1 build is tried and tested and the gripes of those of us > that checked out previous releases have been fixed in the maven1 > build. I guess that doesn't matter if the release is up to scratch but > would be interested to know if others think we're ready for releases > using m2 yet? See for example http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=115714503628112&w=2 http://marc.theaimsgroup.com/?t=11571905414 In those threads Phil points out that the Maven-2 sites need to look the same as the current Commons sites. There are a couple of sandbox components using Maven-2 sites as a test - csv is one; but the css isn't right yet. Dennis (I think) talked about needing a commons skin for Maven-2. > The first issue I have with checking out this RC is that you've only > posted the "tar.gz" source and binary distros. I would have liked to > see the full set - zip versions and md5 checksums (the maven1 build > for fileupload creates the md5 checksums for you). Are you actually going to tell me, that this is an issue? (The archive type, not the checksum, which must of course, be added to distributables. As are .sha1 and .asc files, btw.) If so, changing it is as simple as adding one line to the assembly descriptor. But who do you believe is unable to use tar.gz in 2006? Windows XP can do zip and not tar.gz right? [without extra software]. And irritatingly, many Linux servers can do tar.gz and not zip. Anyway, we produce both as the others have said. > 3) The clirr report you produced: which shows the following > incompatibilities with the previous fileupload version: > > 1) FileUploadBase - public constant MAX_HEADER_SIZE removed. > 2) FileUploadBase - protected method createItem removed > 3) FileUploadBase - two public constructors for > SizeLimitExceededException removed > 4) FileUploadBase - public static class UnknownSizeException removed > 5) MulitpartStream - gone from public to package visibility 1) A maximum header size no longer exists. See FILEUPLOAD-108. 2)+5) See http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=114988352104258&w=2 4) This exception can no longer be thrown, because content-length=-1 is allowed now. All in all, do you really think that's as big an issue as you make it? We try very hard nowadays to make sure our versioning is correct. A minor release should have backwards compat - though I'm personally happy with things being removed if their existence is considered a bug (ie: 5). Might be that we need to call this 2.0. In that case, we might want to consider more API change - ie: removal of DefaultFileItem (?). > One thing thats disappointing is that the last fileupload release had > only 5 checkstyle issues. This one has 376 of which 200 are for tab > characters which I personally dislike in source. The reason is, IMO, that checkstyle is quite outdated. Examples: - Why should I add a comment to a field called serialalversionuid? - Why should I add a comment to an implementation or overwritten superclass method, when I know that the doclet will simply copy the interface or This is a failing in Checkstyle I think. At this point the tail is wagging the dog, so I'm +1 to ignoring these. Niall has a good point that the noise of all the ignored Javadoc issues hides the important things - but it's checkstyle not pmd/findbugs and you can still sift through noise. - It's ridiculous to require comments for private fields, even if they are simply storage for getters and setters. - What's the problem with trailing blanks? (I can understand your sentiment against tabs, btw.) Many +1s on the tabs. Trailing blanks are unnecessary, so no reason not to remove them. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Release commons-fileupload 1.2
On 11/27/06, Martin Cooper <[EMAIL PROTECTED]> wrote: Of course it is. These changes are incompatible in that some people's code will no longer compile against the new version. In this particular case, the situation is like this: If people are actually depending on the presence of this code, then they have, for example, that this exception is thrown. An assumption, on which they possibly depend, and which is no longer true. My personal style of coding is that I would always prefer to be notified of such issues in a very clear manner rather than having someone who ensures that I believe everything is alright. Besides, let me quote yourself: Multipartstream isn't (supposed to be) part of the public API Sigh, I'll reintroduce this nonsense. I'm sorry, but I find your attitude quite disturbing here. You come in on a project that has been very close to Checkstyle-clean for years, you make changes that introduce hundreds of new violations, and you have the gall to say that you refuse to fix the ones you don't agree with? That's not how we work here at Commons either. Yes, I share the feeling that this is not the style of work at Commons. It rather seems to be having someone to pick up an almost dead project, revitalize it with radical internal changes at the cost of almost no public API change, give him no freedback without request and even then almost no response to questions, suggestions and votes (you being the almost sole exception), but whenever it comes to a release, force him to do the important stuff like removing trailing blanks, convert tabs into blanks, comment methods like SomeInputStream.(close|read), and stuff like that. Sorry, but I do indeed have gall in the sense of coming up from my waist. Jochen -- My wife Mary and I have been married for forty-seven years and not once have we had an argument serious enough to consider divorce; murder, yes, but divorce, never. (Jack Benny) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Release commons-fileupload 1.2
On 11/26/06, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: Hi, Niall, On 11/26/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: > I would have preferred the release be cut using maven1 rather than m2. > The maven1 build is tried and tested and the gripes of those of us > that checked out previous releases have been fixed in the maven1 > build. I guess that doesn't matter if the release is up to scratch but > would be interested to know if others think we're ready for releases > using m2 yet? See for example http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=115714503628112&w=2 http://marc.theaimsgroup.com/?t=11571905414 > The first issue I have with checking out this RC is that you've only > posted the "tar.gz" source and binary distros. I would have liked to > see the full set - zip versions and md5 checksums (the maven1 build > for fileupload creates the md5 checksums for you). Are you actually going to tell me, that this is an issue? (The archive type, not the checksum, which must of course, be added to distributables. As are .sha1 and .asc files, btw.) If so, changing it is as simple as adding one line to the assembly descriptor. But who do you believe is unable to use tar.gz in 2006? All Commons components are released with both .zip and .tar.gz files. I don't see a reason to change that now. And yes, I believe there are people who either don't have tools to explode .tar.gz files or don't know that they have such tools. I think there are three serious issues with this RC: > 1) It doesn't comply with the new "ASF Source Header and Copyright > Notice Policy": > http://www.apache.org/legal/src-headers.html I wasn't aware of a change in policy. You are right, that must be honoured. However, you already did it, so it cannot be counted as a reason for a -1, right? The current vote is on the distributables referenced in the VOTE message that started this thread. Any changes made to the source tree since that vote was started do _not_ affect this vote thread in any way. Once a new set of distributables is created, and a new vote thread started, people can vote differently from how they did on the current distributables, but vote threads don't ever reference moving targets. 2) According to the jar's manifest file its been built using JDK > 1.6.0-rc. Even if JDK 1.6 had been (just) released using it for a > release would make me nervous - but using a RC version of Java to cut > the fileupload release is bad news IMO. Ok, I'll keep that in mind for the next approach. > 3) The clirr report you produced: which shows the following > incompatibilities with the previous fileupload version: > > 1) FileUploadBase - public constant MAX_HEADER_SIZE removed. > 2) FileUploadBase - protected method createItem removed > 3) FileUploadBase - two public constructors for > SizeLimitExceededException removed > 4) FileUploadBase - public static class UnknownSizeException removed > 5) MulitpartStream - gone from public to package visibility 1) A maximum header size no longer exists. See FILEUPLOAD-108. 2)+5) See http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=114988352104258&w=2 4) This exception can no longer be thrown, because content-length=-1 is allowed now. All in all, do you really think that's as big an issue as you make it? Of course it is. These changes are incompatible in that some people's code will no longer compile against the new version. The API contract has been broken. Further, the changes were not preceded by deprecations, so people who don't follow ongoing development will suddenly find their code broken, rather than having had advance warning through deprecations. Perhaps if this was a major version upgrade, this _might_ be acceptable, but it's certainly not acceptable for a minor version upgrade, at least here at Jakarta Commons. One thing thats disappointing is that the last fileupload release had > only 5 checkstyle issues. This one has 376 of which 200 are for tab > characters which I personally dislike in source. The reason is, IMO, that checkstyle is quite outdated. Examples: - Why should I add a comment to a field called serialalversionuid? - Why should I add a comment to an implementation or overwritten superclass method, when I know that the doclet will simply copy the interface or - It's ridiculous to require comments for private fields, even if they are simply storage for getters and setters. - What's the problem with trailing blanks? (I can understand your sentiment against tabs, btw.) Please note, that I have enabled almost any warning that Eclipse can trigger. And, believe me, these are more and more serious matters than checkstyle detects. Nevertheless, I have eliminated almost all warnings today, except those I cannot omit and I refuse to remove, because I know better than checkstyle that it makes sense to keep them. The code I have added contains *no* Eclipse warning. Elder code does. I'm sorry, but I find your att
Re: VOTE: Release commons-fileupload 1.2
On 11/27/06, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: Hi, Niall, On 11/26/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: > I would have preferred the release be cut using maven1 rather than m2. > The maven1 build is tried and tested and the gripes of those of us > that checked out previous releases have been fixed in the maven1 > build. I guess that doesn't matter if the release is up to scratch but > would be interested to know if others think we're ready for releases > using m2 yet? See for example http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=115714503628112&w=2 http://marc.theaimsgroup.com/?t=11571905414 > The first issue I have with checking out this RC is that you've only > posted the "tar.gz" source and binary distros. I would have liked to > see the full set - zip versions and md5 checksums (the maven1 build > for fileupload creates the md5 checksums for you). Are you actually going to tell me, that this is an issue? (The archive type, not the checksum, which must of course, be added to distributables. As are .sha1 and .asc files, btw.) If so, changing it is as simple as adding one line to the assembly descriptor. But who do you believe is unable to use tar.gz in 2006? I actually assumed you just hadn't uploaded them. But I'm glad now I raised it since zip distros are artifacts the release should have (whether you think they're a waste of time or not) - as the build wasn't actually generating them then obviously it was a flaw which needed fixing - which I'm glad you now have. The real underlying issue here though is that I haven't seen you do a release before - so I have nothing to give me confidence. The way to starting building that is to at least produce all the artifacts for the release. I'd have been happier if you'd followed what people usually do - tagged the repository, cut the release candidate, made it available for review and then called a vote. You don't have to do any of this, but you're more likely to get my vote if you do - and its what I and quite a few others do: http://people.apache.org/~niallp/validator-1.3.1-rc1/ http://people.apache.org/~rahul/commons/digester/ http://people.apache.org/~bayard/commons-dbutils/1.1-RC1/ > I think there are three serious issues with this RC: > 1) It doesn't comply with the new "ASF Source Header and Copyright > Notice Policy": > http://www.apache.org/legal/src-headers.html I wasn't aware of a change in policy. You are right, that must be honoured. However, you already did it, so it cannot be counted as a reason for a -1, right? Its a -1 for RC1 - now its fixed though should mean its not an issue if you cut a RC2 > 2) According to the jar's manifest file its been built using JDK > 1.6.0-rc. Even if JDK 1.6 had been (just) released using it for a > release would make me nervous - but using a RC version of Java to cut > the fileupload release is bad news IMO. Ok, I'll keep that in mind for the next approach. > 3) The clirr report you produced: which shows the following > incompatibilities with the previous fileupload version: > > 1) FileUploadBase - public constant MAX_HEADER_SIZE removed. > 2) FileUploadBase - protected method createItem removed > 3) FileUploadBase - two public constructors for > SizeLimitExceededException removed > 4) FileUploadBase - public static class UnknownSizeException removed > 5) MulitpartStream - gone from public to package visibility 1) A maximum header size no longer exists. See FILEUPLOAD-108. 2)+5) See http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=114988352104258&w=2 4) This exception can no longer be thrown, because content-length=-1 is allowed now. All in all, do you really think that's as big an issue as you make it? I think breaking backwards compatibility in a widely used library like fileupload is a serious issue and as no-one else had reviewed your release candidate I think highlighting it was important. I agree the issues don't look big - but in terms of compatibility one small change could cause jar hell in a widely used library. Have you at least done anything to verify whether any of these changes cause a problem with any of the frameworks that use fileupload? I only went by the clirr report and am not famailiar with why you removed these - but its obvious that at least some of them (if not all) could have been deprecated rather than removed. If there are good reasons why breaking binary compatibility is preferable (or necessary) to deprecating then IMO it would be good for you to state them and then it needs to be decided whether putting out an incompatible release is acceptable or the package name name should be changed: http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg85642.html > One thing thats disappointing is that the last fileupload release had > only 5 checkstyle issues. This one has 376 of which 200 are for tab > characters which I personally dislike in source. The reason is, IMO, that checksty
Re: VOTE: Release commons-fileupload 1.2
Hi, Niall, On 11/26/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: I would have preferred the release be cut using maven1 rather than m2. The maven1 build is tried and tested and the gripes of those of us that checked out previous releases have been fixed in the maven1 build. I guess that doesn't matter if the release is up to scratch but would be interested to know if others think we're ready for releases using m2 yet? See for example http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=115714503628112&w=2 http://marc.theaimsgroup.com/?t=11571905414 The first issue I have with checking out this RC is that you've only posted the "tar.gz" source and binary distros. I would have liked to see the full set - zip versions and md5 checksums (the maven1 build for fileupload creates the md5 checksums for you). Are you actually going to tell me, that this is an issue? (The archive type, not the checksum, which must of course, be added to distributables. As are .sha1 and .asc files, btw.) If so, changing it is as simple as adding one line to the assembly descriptor. But who do you believe is unable to use tar.gz in 2006? I think there are three serious issues with this RC: 1) It doesn't comply with the new "ASF Source Header and Copyright Notice Policy": http://www.apache.org/legal/src-headers.html I wasn't aware of a change in policy. You are right, that must be honoured. However, you already did it, so it cannot be counted as a reason for a -1, right? 2) According to the jar's manifest file its been built using JDK 1.6.0-rc. Even if JDK 1.6 had been (just) released using it for a release would make me nervous - but using a RC version of Java to cut the fileupload release is bad news IMO. Ok, I'll keep that in mind for the next approach. 3) The clirr report you produced: which shows the following incompatibilities with the previous fileupload version: 1) FileUploadBase - public constant MAX_HEADER_SIZE removed. 2) FileUploadBase - protected method createItem removed 3) FileUploadBase - two public constructors for SizeLimitExceededException removed 4) FileUploadBase - public static class UnknownSizeException removed 5) MulitpartStream - gone from public to package visibility 1) A maximum header size no longer exists. See FILEUPLOAD-108. 2)+5) See http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=114988352104258&w=2 4) This exception can no longer be thrown, because content-length=-1 is allowed now. All in all, do you really think that's as big an issue as you make it? One thing thats disappointing is that the last fileupload release had only 5 checkstyle issues. This one has 376 of which 200 are for tab characters which I personally dislike in source. The reason is, IMO, that checkstyle is quite outdated. Examples: - Why should I add a comment to a field called serialalversionuid? - Why should I add a comment to an implementation or overwritten superclass method, when I know that the doclet will simply copy the interface or - It's ridiculous to require comments for private fields, even if they are simply storage for getters and setters. - What's the problem with trailing blanks? (I can understand your sentiment against tabs, btw.) Please note, that I have enabled almost any warning that Eclipse can trigger. And, believe me, these are more and more serious matters than checkstyle detects. Nevertheless, I have eliminated almost all warnings today, except those I cannot omit and I refuse to remove, because I know better than checkstyle that it makes sense to keep them. The code I have added contains *no* Eclipse warning. Elder code does. Jochen -- My wife Mary and I have been married for forty-seven years and not once have we had an argument serious enough to consider divorce; murder, yes, but divorce, never. (Jack Benny) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Release commons-fileupload 1.2
I've updated the source file headers to comply with the new policy: http://svn.apache.org/viewvc?view=rev&revision=479262 Also could you update your subversion client to automatically add subversion properties when you add new artifacts - the main one being svn:eol-style. Hopefully I've added svn properties for all the new files you've added: http://svn.apache.org/viewvc?view=rev&revision=479261 More info on svn properties and configuring your client here: http://wiki.apache.org/struts/StrutsMaintenanceSvn Niall On 11/26/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: On 11/15/06, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: > Hi, > > after the release of commons-parent, the hurdles for publishing the > next version of commons-fileupload have now gone. So I'd like to > request a release of > > Commons Fileupload 1.2 > > The proposed distributables can be found at > > http://people.apache.org/~jochen/commons-fileupload/dist > > The proposed web site is at > > http://people.apache.org/~jochen/commons-fileupload/site > > Notable changes in 1.2 are: > > - Made Streams.asString static. Thanks to Aaron Freeman. > - Eliminated duplicate code. (FILEUPLOAD-109) > - Added a streaming API. (FILEUPLOAD-112) > - Eliminated the necessity of a content-length header. (FILEUPLOAD-93) > - Eliminated the limitation of a maximum size for a single header > line. (FILEUPLOAD-108) > Thanks to Amichai Rothman. > - Added the ProgressListener, which allows to implement a progress bar. > (FILEUPLOAD-87) > - Added support for header continuation lines. (FILEUPLOAD-111) > Thanks to Amichai Rothman. > - It is now possible to limit the actual file size and not the request size. > (FILEUPLOAD-88) Thanks to Andrey Aristarkhov. > > > Please cast your vote: > > [] +1 > [] =0 > [] -1 I would have preferred the release be cut using maven1 rather than m2. The maven1 build is tried and tested and the gripes of those of us that checked out previous releases have been fixed in the maven1 build. I guess that doesn't matter if the release is up to scratch but would be interested to know if others think we're ready for releases using m2 yet? The first issue I have with checking out this RC is that you've only posted the "tar.gz" source and binary distros. I would have liked to see the full set - zip versions and md5 checksums (the maven1 build for fileupload creates the md5 checksums for you). I think there are three serious issues with this RC: 1) It doesn't comply with the new "ASF Source Header and Copyright Notice Policy": http://www.apache.org/legal/src-headers.html 2) According to the jar's manifest file its been built using JDK 1.6.0-rc. Even if JDK 1.6 had been (just) released using it for a release would make me nervous - but using a RC version of Java to cut the fileupload release is bad news IMO. 3) The clirr report you produced: which shows the following incompatibilities with the previous fileupload version: 1) FileUploadBase - public constant MAX_HEADER_SIZE removed. 2) FileUploadBase - protected method createItem removed 3) FileUploadBase - two public constructors for SizeLimitExceededException removed 4) FileUploadBase - public static class UnknownSizeException removed 5) MulitpartStream - gone from public to package visibility For these reasons my vote is -1. One thing thats disappointing is that the last fileupload release had only 5 checkstyle issues. This one has 376 of which 200 are for tab characters which I personally dislike in source. Looking at the source distro "rat" report for the nightly build - its showing 7 missing license headers - the 2 that stand out are for the test cases: FileUploadTestCase and ProgressListenerTest: http://vmbuild.apache.org/~commons/nightly/nightly_reports/commons-fileupload/src-rat.txt Niall > Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r479262 [2/2] - in /jakarta/commons/proper/fileupload/trunk: ./ src/changes/ src/checkstyle/ src/java/org/apache/commons/fileupload/ src/java/org/apache/commons/fileupload/disk/ src/java/o
Modified: jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/SizesTest.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/SizesTest.java?view=diff&rev=479262&r1=479261&r2=479262 == --- jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/SizesTest.java (original) +++ jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/SizesTest.java Sat Nov 25 19:09:24 2006 @@ -1,11 +1,12 @@ /* - * Copyright 2001-2004 The Apache Software Foundation + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You 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 * - * 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 + * 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, Modified: jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/StreamingTest.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/StreamingTest.java?view=diff&rev=479262&r1=479261&r2=479262 == --- jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/StreamingTest.java (original) +++ jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/StreamingTest.java Sat Nov 25 19:09:24 2006 @@ -1,11 +1,12 @@ /* - * Copyright 2001-2004 The Apache Software Foundation + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You 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 * - * 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 + * 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, Modified: jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/TestAll.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/TestAll.java?view=diff&rev=479262&r1=479261&r2=479262 ====== --- jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/TestAll.java (original) +++ jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/TestAll.java Sat Nov 25 19:09:24 2006 @@ -1,11 +1,12 @@ /* - * Copyright 2002-2004 The Apache Software Foundation + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You 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 * - * 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 + * 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, Modified: jakarta/commons/proper/fileupload/trunk/xdocs/customizing.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/xdocs/customizing.xml?view=diff&rev=479262&r1=479261&r2=479262
svn commit: r479261 - in /jakarta/commons/proper/fileupload/trunk: ./ src/checkstyle/ src/java/org/apache/commons/fileupload/ src/java/org/apache/commons/fileupload/util/ src/main/assembly/ src/site/
Author: niallp Date: Sat Nov 25 18:40:31 2006 New Revision: 479261 URL: http://svn.apache.org/viewvc?view=rev&rev=479261 Log: Set svn:eol-style to "native" - no actual changes in this commit, but will probably generate alot of noise Modified: jakarta/commons/proper/fileupload/trunk/pom.xml (props changed) jakarta/commons/proper/fileupload/trunk/src/checkstyle/fileupload_basic.xml (contents, props changed) jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileItemIterator.java (props changed) jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileItemStream.java (props changed) jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/ProgressListener.java (props changed) jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/util/Closeable.java (props changed) jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/util/LimitedInputStream.java (props changed) jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/util/Streams.java (props changed) jakarta/commons/proper/fileupload/trunk/src/main/assembly/bin.xml (props changed) jakarta/commons/proper/fileupload/trunk/src/main/assembly/src.xml (props changed) jakarta/commons/proper/fileupload/trunk/src/site/site.xml (props changed) jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/FileUploadTestCase.java (props changed) jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/ProgressListenerTest.java (props changed) jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/SizesTest.java (props changed) jakarta/commons/proper/fileupload/trunk/src/test/org/apache/commons/fileupload/StreamingTest.java (props changed) jakarta/commons/proper/fileupload/trunk/xdocs/streaming.xml (props changed) Propchange: jakarta/commons/proper/fileupload/trunk/pom.xml -- svn:eol-style = native Modified: jakarta/commons/proper/fileupload/trunk/src/checkstyle/fileupload_basic.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/checkstyle/fileupload_basic.xml?view=diff&rev=479261&r1=479260&r2=479261 == --- jakarta/commons/proper/fileupload/trunk/src/checkstyle/fileupload_basic.xml (original) +++ jakarta/commons/proper/fileupload/trunk/src/checkstyle/fileupload_basic.xml Sat Nov 25 18:40:31 2006 @@ -2,8 +2,8 @@ PMD Basic Ruleset minus the EmptyCatchBlock rule. - - - - - + + + + + Propchange: jakarta/commons/proper/fileupload/trunk/src/checkstyle/fileupload_basic.xml -- svn:eol-style = native Propchange: jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileItemIterator.java -- svn:eol-style = native Propchange: jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileItemIterator.java -- svn:keywords = Date Author Id Revision HeadURL Propchange: jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileItemStream.java -- svn:eol-style = native Propchange: jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/FileItemStream.java -- svn:keywords = Date Author Id Revision HeadURL Propchange: jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/ProgressListener.java -- svn:eol-style = native Propchange: jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/ProgressListener.java -- svn:keywords = Date Author Id Revision HeadURL Propchange: jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/util/Closeable.java -- svn:eol-style = native Propchange: jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/util/Closeable.java -- svn:keywords = Date Author Id Revision HeadURL Propchange: jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/ut
Re: VOTE: Release commons-fileupload 1.2
On 11/15/06, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
Hi,
after the release of commons-parent, the hurdles for publishing the
next version of commons-fileupload have now gone. So I'd like to
request a release of
Commons Fileupload 1.2
The proposed distributables can be found at
http://people.apache.org/~jochen/commons-fileupload/dist
The proposed web site is at
http://people.apache.org/~jochen/commons-fileupload/site
Notable changes in 1.2 are:
- Made Streams.asString static. Thanks to Aaron Freeman.
- Eliminated duplicate code. (FILEUPLOAD-109)
- Added a streaming API. (FILEUPLOAD-112)
- Eliminated the necessity of a content-length header. (FILEUPLOAD-93)
- Eliminated the limitation of a maximum size for a single header
line. (FILEUPLOAD-108)
Thanks to Amichai Rothman.
- Added the ProgressListener, which allows to implement a progress bar.
(FILEUPLOAD-87)
- Added support for header continuation lines. (FILEUPLOAD-111)
Thanks to Amichai Rothman.
- It is now possible to limit the actual file size and not the request size.
(FILEUPLOAD-88) Thanks to Andrey Aristarkhov.
Please cast your vote:
[] +1
[] =0
[] -1
I would have preferred the release be cut using maven1 rather than m2.
The maven1 build is tried and tested and the gripes of those of us
that checked out previous releases have been fixed in the maven1
build. I guess that doesn't matter if the release is up to scratch but
would be interested to know if others think we're ready for releases
using m2 yet?
The first issue I have with checking out this RC is that you've only
posted the "tar.gz" source and binary distros. I would have liked to
see the full set - zip versions and md5 checksums (the maven1 build
for fileupload creates the md5 checksums for you).
I think there are three serious issues with this RC:
1) It doesn't comply with the new "ASF Source Header and Copyright
Notice Policy":
http://www.apache.org/legal/src-headers.html
2) According to the jar's manifest file its been built using JDK
1.6.0-rc. Even if JDK 1.6 had been (just) released using it for a
release would make me nervous - but using a RC version of Java to cut
the fileupload release is bad news IMO.
3) The clirr report you produced: which shows the following
incompatibilities with the previous fileupload version:
1) FileUploadBase - public constant MAX_HEADER_SIZE removed.
2) FileUploadBase - protected method createItem removed
3) FileUploadBase - two public constructors for
SizeLimitExceededException removed
4) FileUploadBase - public static class UnknownSizeException removed
5) MulitpartStream - gone from public to package visibility
For these reasons my vote is -1.
One thing thats disappointing is that the last fileupload release had
only 5 checkstyle issues. This one has 376 of which 200 are for tab
characters which I personally dislike in source.
Looking at the source distro "rat" report for the nightly build - its
showing 7 missing license headers - the 2 that stand out are for the
test cases: FileUploadTestCase and ProgressListenerTest:
http://vmbuild.apache.org/~commons/nightly/nightly_reports/commons-fileupload/src-rat.txt
Niall
Jochen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Release commons-fileupload 1.2
On 11/16/06, Martin Cooper <[EMAIL PROTECTED]> wrote: 1) Given the significant API changes since 1.1.1, I would like to see clirr and jdiff reports, so that we can verify backwards compatibility more reliably. I have created a clirr report on http://people.apache.org/~jochen/commons-fileupload/clirr.txt Haven't got jdiff to work. 2) I would like to see the output of Robert's RAT tool, run over the proposed distro, to make sure were not missing anything. http://people.apache.org/~jochen/commons-fileupload/bin-rat.txt http://people.apache.org/~jochen/commons-fileupload/src-rat.txt -- My wife Mary and I have been married for forty-seven years and not once have we had an argument serious enough to consider divorce; murder, yes, but divorce, never. (Jack Benny) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Release commons-fileupload 1.2
On 11/15/06, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
Hi,
after the release of commons-parent, the hurdles for publishing the
next version of commons-fileupload have now gone. So I'd like to
request a release of
Commons Fileupload 1.2
I'm not going to have time to look at this until the weekend, but I will try
to spend some time on it then. In the meantime, a couple of requests:
1) Given the significant API changes since 1.1.1, I would like to see clirr
and jdiff reports, so that we can verify backwards compatibility more
reliably.
2) I would like to see the output of Robert's RAT tool, run over the
proposed distro, to make sure were not missing anything.
--
Martin Cooper
The proposed distributables can be found at
http://people.apache.org/~jochen/commons-fileupload/dist
The proposed web site is at
http://people.apache.org/~jochen/commons-fileupload/site
Notable changes in 1.2 are:
- Made Streams.asString static. Thanks to Aaron Freeman.
- Eliminated duplicate code. (FILEUPLOAD-109)
- Added a streaming API. (FILEUPLOAD-112)
- Eliminated the necessity of a content-length header. (FILEUPLOAD-93)
- Eliminated the limitation of a maximum size for a single header
line. (FILEUPLOAD-108)
Thanks to Amichai Rothman.
- Added the ProgressListener, which allows to implement a progress bar.
(FILEUPLOAD-87)
- Added support for header continuation lines. (FILEUPLOAD-111)
Thanks to Amichai Rothman.
- It is now possible to limit the actual file size and not the request
size.
(FILEUPLOAD-88) Thanks to Andrey Aristarkhov.
Please cast your vote:
[] +1
[] =0
[] -1
Jochen
--
My wife Mary and I have been married for forty-seven years and not
once have we had an argument serious enough to consider divorce;
murder, yes, but divorce, never.
(Jack Benny)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
VOTE: Release commons-fileupload 1.2
Hi, after the release of commons-parent, the hurdles for publishing the next version of commons-fileupload have now gone. So I'd like to request a release of Commons Fileupload 1.2 The proposed distributables can be found at http://people.apache.org/~jochen/commons-fileupload/dist The proposed web site is at http://people.apache.org/~jochen/commons-fileupload/site Notable changes in 1.2 are: - Made Streams.asString static. Thanks to Aaron Freeman. - Eliminated duplicate code. (FILEUPLOAD-109) - Added a streaming API. (FILEUPLOAD-112) - Eliminated the necessity of a content-length header. (FILEUPLOAD-93) - Eliminated the limitation of a maximum size for a single header line. (FILEUPLOAD-108) Thanks to Amichai Rothman. - Added the ProgressListener, which allows to implement a progress bar. (FILEUPLOAD-87) - Added support for header continuation lines. (FILEUPLOAD-111) Thanks to Amichai Rothman. - It is now possible to limit the actual file size and not the request size. (FILEUPLOAD-88) Thanks to Andrey Aristarkhov. Please cast your vote: [] +1 [] =0 [] -1 Jochen -- My wife Mary and I have been married for forty-seven years and not once have we had an argument serious enough to consider divorce; murder, yes, but divorce, never. (Jack Benny) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r469386 - in /jakarta/commons/proper/fileupload/trunk: pom.xml src/changes/changes.xml src/java/org/apache/commons/fileupload/util/Streams.java
Author: jochen
Date: Mon Oct 30 22:10:04 2006
New Revision: 469386
URL: http://svn.apache.org/viewvc?view=rev&rev=469386
Log:
Made Streams.asString static.
Modified:
jakarta/commons/proper/fileupload/trunk/pom.xml
jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/util/Streams.java
Modified: jakarta/commons/proper/fileupload/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/pom.xml?view=diff&rev=469386&r1=469385&r2=469386
==
--- jakarta/commons/proper/fileupload/trunk/pom.xml (original)
+++ jakarta/commons/proper/fileupload/trunk/pom.xml Mon Oct 30 22:10:04 2006
@@ -77,6 +77,10 @@
+ Aaron Freeman
+ [EMAIL PROTECTED]
+
+
Amichai Rothman
[EMAIL PROTECTED]
Modified: jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml?view=diff&rev=469386&r1=469385&r2=469386
==
--- jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml (original)
+++ jakarta/commons/proper/fileupload/trunk/src/changes/changes.xml Mon Oct 30
22:10:04 2006
@@ -42,6 +42,11 @@
+
+Made Streams.asString static.
+
+
Eliminated duplicate code.
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/util/Streams.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/util/Streams.java?view=diff&rev=469386&r1=469385&r2=469386
==
---
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/util/Streams.java
(original)
+++
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/util/Streams.java
Mon Oct 30 22:10:04 2006
@@ -125,7 +125,7 @@
* @param pStream The input stream to read.
* @see #asString(InputStream, String)
*/
-public String asString(InputStream pStream) throws IOException {
+public static String asString(InputStream pStream) throws IOException {
ByteArrayOutputStream baos = new ByteArrayOutputStream();
copy(pStream, baos, true);
return baos.toString();
@@ -138,7 +138,7 @@
* @param pEncoding The character encoding, typically "UTF-8".
* @see #asString(InputStream)
*/
-public String asString(InputStream pStream, String pEncoding)
+public static String asString(InputStream pStream, String pEncoding)
throws IOException {
ByteArrayOutputStream baos = new ByteArrayOutputStream();
copy(pStream, baos, true);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Migrate commons-fileupload to Maven 2
Dion Gillard wrote: Does this work without any snapshot dependencies on plugins or m2 itself. Currently there is a dependency on a snapshot of the maven-changes-plugin. I'll try to fix this by getting a release of the changes plugin. Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Migrate commons-fileupload to Maven 2
Does this work without any snapshot dependencies on plugins or m2 itself. On 9/2/06, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: Hi, I have just checked in the required changes for building site and distribution of commons-fileupload with Maven 2. See http://people.apache.org/~jochen/commons-fileupload for details. Now that is done, I'd like to get rid of the Maven 1 stuff. In particular, I'd like to change the project layout, so that it matches the Maven 2 standards. Additionally, I'd like to remove the files project.(properties|xml) and maven.xml, as well as xdocs/navigation.xml. Regards, Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ Rule #91: Hear all, trust nothing. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Migrate commons-fileupload to Maven 2
Craig McClanahan wrote: On 9/1/06, Phil Steitz <[EMAIL PROTECTED]> wrote: We also need to definitively settle the artifact naming conventions and think carefully about the impact of relocating the fileupload jar. I *think* the following strategy will deal with this situation ... and should generic to all the commons packages: * If version x.y.z of Commons package "foo" is published as Maven artifact "commons-foo:commons-foo:x.y.z", publish an *additional* copy of that same version under "org.apache.commons.foo:commons-foo:x.y.z". * For all future versions, use only the"org.apache.commons" group id. That way, we won't disrupt current Maven-based users of the current versions, and we also don't have to wait until each individual package revs to publish versions under the new id. Users who are updating their projects to depend on a new version number can easily update the group id at the same time. Does that make any sense? Phil Craig I've documented the procedure for doing this here: http://maven.apache.org/guides/mini/guide-relocation.html -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons and Maven 2 (Was: VOTE: Migrate commons-fileupload to Maven 2)
On 9/4/06, Phil Steitz <[EMAIL PROTECTED]> wrote: Thanks, Wendy. How do you force maven to use an earlier version? Adding a plugin element for the site plugin with a version spec did not seem to work for me - at least according to what I saw from -X. Where do you put the plugin element to specify the older version? We have it in in the parent pom: http://svn.apache.org/repos/asf/struts/struts1/trunk/pom.xml If it's in the pom for the actual module, then ... should work. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons and Maven 2 (Was: VOTE: Migrate commons-fileupload to Maven 2)
On 9/4/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: On 9/4/06, Phil Steitz <[EMAIL PROTECTED]> wrote: > OK - I guess that's why I couldn't find it ;-) I assume the latest > (released) site plugin (2.0-beta-5) is OK to use, right? 2.0-beta-5 has some annoying issues... Shale and Struts are still using 2.0-beta-4 until there is another release. Thanks, Wendy. How do you force maven to use an earlier version? Adding a plugin element for the site plugin with a version spec did not seem to work for me - at least according to what I saw from -X. Where do you put the plugin element to specify the older version? Phil -- Wendy - 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: Commons and Maven 2 (Was: VOTE: Migrate commons-fileupload to Maven 2)
On 9/4/06, Phil Steitz <[EMAIL PROTECTED]> wrote: OK - I guess that's why I couldn't find it ;-) I assume the latest (released) site plugin (2.0-beta-5) is OK to use, right? 2.0-beta-5 has some annoying issues... Shale and Struts are still using 2.0-beta-4 until there is another release. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons and Maven 2 (Was: VOTE: Migrate commons-fileupload to Maven 2)
On 9/3/06, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: Phil Steitz wrote: > current released plugin versions would be most appreciated. Where, by > the way, are you getting the maven-changes-plugin for [fileupload]? Oops, you are right! I am using a snapshot version myself. I have asked for a release on dev@maven.apache.org in order to get this fixed. OK - I guess that's why I couldn't find it ;-) I assume the latest (released) site plugin (2.0-beta-5) is OK to use, right? I also figured out what is going on with the menus / style stuff. The sanbox components are inheriting this from the commons-sandbox POM. If we want to use this approach to standardize the l & f of all of the sites for m2, we need to add site resources to trunks-proper as well. Until reading http://maven.apache.org/plugins/maven-site-plugin/howto.html, I did not realize that site configuration was packaged with a POM. Seems odd to me and not obvious that we would want to release this config with the parent POM. Is there a way that we can achieve the same effect (make it easy for component sites to reuse menus / style info) without tightly coupling the site config with the parent POM? We need to be able to build and deploy the component sites independently. Phil Jochen - 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: Commons and Maven 2 (Was: VOTE: Migrate commons-fileupload to Maven 2)
Phil Steitz wrote: current released plugin versions would be most appreciated. Where, by the way, are you getting the maven-changes-plugin for [fileupload]? Oops, you are right! I am using a snapshot version myself. I have asked for a release on dev@maven.apache.org in order to get this fixed. Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons and Maven 2 (Was: VOTE: Migrate commons-fileupload to Maven 2)
Yes. We should avoid snapshot dependencies. I think when that page was written, the site plugin had not been released yet. I have not yet succeeded in duplicating / reverse engineering the setup to get this working and updated. Updates based on working examples using current released plugin versions would be most appreciated. Where, by the way, are you getting the maven-changes-plugin for [fileupload]? Phil On 9/3/06, Jörg Schaible <[EMAIL PROTECTED]> wrote: ochen Wiedmann wrote on Sunday, September 03, 2006 9:53 PM: > Hi, > > I attempted to build the site of commons-fileupload, following the > instruction from > > http://wiki.apache.org/jakarta-commons/CreatingSiteWithMaven2 > > (To be precise, I simply made sure, that the latest snapshot of the > maven-site-plugin is being used. I found no other instructions that I > should follow.) > > Unfortunately, the build failed, most possibly because of an error in > the site plugin or one of its dependencies. (I've got a > ClassNotFoundException.) > > Regardless of the above problems, I also do believe that using a > snapshot plugin should be avoided. As the site builds very well with > the released version, I am currently simply ignoring the instructions > on CreatingSiteWithMaven2. Another reson to avoid SNAPSHOT-plugins: The release plugin will not build a release while you depend on anything using a SNAPSHOIT version! ;-) - Jörg - 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: Commons and Maven 2 (Was: VOTE: Migrate commons-fileupload to Maven 2)
Jochen Wiedmann wrote on Sunday, September 03, 2006 9:53 PM: > Hi, > > I attempted to build the site of commons-fileupload, following the > instruction from > > http://wiki.apache.org/jakarta-commons/CreatingSiteWithMaven2 > > (To be precise, I simply made sure, that the latest snapshot of the > maven-site-plugin is being used. I found no other instructions that I > should follow.) > > Unfortunately, the build failed, most possibly because of an error in > the site plugin or one of its dependencies. (I've got a > ClassNotFoundException.) > > Regardless of the above problems, I also do believe that using a > snapshot plugin should be avoided. As the site builds very well with > the released version, I am currently simply ignoring the instructions > on CreatingSiteWithMaven2. Another reson to avoid SNAPSHOT-plugins: The release plugin will not build a release while you depend on anything using a SNAPSHOIT version! ;-) - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons and Maven 2 (Was: VOTE: Migrate commons-fileupload to Maven 2)
Hi, I attempted to build the site of commons-fileupload, following the instruction from http://wiki.apache.org/jakarta-commons/CreatingSiteWithMaven2 (To be precise, I simply made sure, that the latest snapshot of the maven-site-plugin is being used. I found no other instructions that I should follow.) Unfortunately, the build failed, most possibly because of an error in the site plugin or one of its dependencies. (I've got a ClassNotFoundException.) Regardless of the above problems, I also do believe that using a snapshot plugin should be avoided. As the site builds very well with the released version, I am currently simply ignoring the instructions on CreatingSiteWithMaven2. Jochen -- My wife Mary and I have been married for forty-seven years and not once have we had an argument serious enough to consider divorce; murder, yes, but divorce, never. (Jack Benny) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons and Maven 2 (Was: VOTE: Migrate commons-fileupload to Maven 2)
On 9/2/06, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: On 9/2/06, Phil Steitz <[EMAIL PROTECTED]> wrote: > I will add some comments to the commons pom itself and once things > have stabilized, add a maven 2 section (or I guess rewrite these pages > for m2) to the "building.." and "releasing..." pages to doc all of > this (unless, of course, someone else beats me to it :-). Btw, where's the pom located in CVS? I have looked into jakarta/commons/proper, but it doesn't seem to be there? /jakarta/commons/trunks-proper/pom.xml Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r439664 - /jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/ProgressListener.java
Author: jochen
Date: Sat Sep 2 14:46:49 2006
New Revision: 439664
URL: http://svn.apache.org/viewvc?rev=439664&view=rev
Log:
Eliminated tab characters.
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/ProgressListener.java
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/ProgressListener.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/ProgressListener.java?rev=439664&r1=439663&r2=439664&view=diff
==
---
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/ProgressListener.java
(original)
+++
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/ProgressListener.java
Sat Sep 2 14:46:49 2006
@@ -21,13 +21,13 @@
* or do stuff like that.
*/
public interface ProgressListener {
- /** Updates the listeners status information.
-* @param pBytesRead The total number of bytes, which have been read
-* so far.
-* @param pContentLength The total number of bytes, which are being
-* read. May be -1, if this number is unknown.
-* @param pItems The number of the field, which is currently being
-* read. (0 = no item so far, 1 = first item is being read, ...)
-*/
- void update(long pBytesRead, long pContentLength, int pItems);
+/** Updates the listeners status information.
+ * @param pBytesRead The total number of bytes, which have been read
+ * so far.
+ * @param pContentLength The total number of bytes, which are being
+ * read. May be -1, if this number is unknown.
+ * @param pItems The number of the field, which is currently being
+ * read. (0 = no item so far, 1 = first item is being read, ...)
+ */
+void update(long pBytesRead, long pContentLength, int pItems);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r439661 - /jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/util/Streams.java
Author: jochen Date: Sat Sep 2 14:38:32 2006 New Revision: 439661 URL: http://svn.apache.org/viewvc?rev=439661&view=rev Log: Added missing copyright header. Modified: jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/util/Streams.java Modified: jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/util/Streams.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/util/Streams.java?rev=439661&r1=439660&r2=439661&view=diff == --- jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/util/Streams.java (original) +++ jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/util/Streams.java Sat Sep 2 14:38:32 2006 @@ -1,3 +1,18 @@ +/* + * Copyright 2006 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. + */ package org.apache.commons.fileupload.util; import java.io.ByteArrayOutputStream; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons and Maven 2 (Was: VOTE: Migrate commons-fileupload to Maven 2)
On 9/2/06, Phil Steitz <[EMAIL PROTECTED]> wrote: I will add some comments to the commons pom itself and once things have stabilized, add a maven 2 section (or I guess rewrite these pages for m2) to the "building.." and "releasing..." pages to doc all of this (unless, of course, someone else beats me to it :-). Btw, where's the pom located in CVS? I have looked into jakarta/commons/proper, but it doesn't seem to be there? Jochen -- My wife Mary and I have been married for forty-seven years and not once have we had an argument serious enough to consider divorce; murder, yes, but divorce, never. (Jack Benny) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Migrate commons-fileupload to Maven 2
Jochen Wiedmann wrote: > > Hi, > > I have just checked in the required changes for building site and > distribution of commons-fileupload with Maven 2. See > > http://people.apache.org/~jochen/commons-fileupload > > for details. Now that is done, I'd like to get rid of the Maven 1 > stuff. In particular, I'd like to change the project layout, so that it > matches the Maven 2 standards. Additionally, I'd like to remove the > files project.(properties|xml) and maven.xml, as well as > xdocs/navigation.xml. +1 - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
