Re: [5.0] fileupload 1.0 RC 1 API breakage
Glenn Nielsen wrote: Martin Cooper wrote: Get your own act together, Tomcat developers, before you start pointing the finger at those of us who really try hard to maintain compatibility across Jakarta projects. Was this really necessary? The email below went to both the commons-dev and tomcat -dev lists. If Remy was pointing the finger at anyone, it was at his fellow Tomcat Developers. Thats how I interpreted it. We (tomcat devs) will fix use of FileUpload in Tomcat and move on, no big deal. Sorry for the tone of the original email; I wasn't upset anyway, it was just a quickly drafted email this morning before leaving to work (having no access to my Apache email during the day). BTW, I am not subscribed to commons-dev. I saw about the new Disk* classes browsing archives, but didn't do a parallel. One last note: IMO, as a rule (and esp in the commons), you should make every effort to avoid breaking the API between a beta and a final. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] fileupload 1.0 RC 1 API breakage
One last note: IMO, as a rule (and esp in the commons), you should make every effort to avoid breaking the API between a beta and a final. FileUpload did not go final, if went to RC1. Changes between RCs and final could be considered inappropriate but not from beta to RC. See the Release Types Beta Releases section here: http://jakarta.apache.org/commons/versioning.html David Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] fileupload 1.0 RC 1 API breakage
FileUpload.setRepositoryPath(String) and FileItem(String) were removed from the fileupload RC 1 release, which breaks the Tomcat 4.1.x and 5.0.x build. The first method has no apparent replacement (but I didn't try to dig around). This is clearly an unacceptable situation from the Tomcat perspective :-( I'm hoping there can be positive solutions to the problem ... There is absolutely no API guarantee between beta releases. Martin has posted several messages to commons-dev about the changes and has apparently even posted a patch for Tomcat. Instead of complaining about one broken build you should be thanking Martin for being the sole developer on FileUpload. David Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] fileupload 1.0 RC 1 API breakage
At 7:38 -0500 6/4/03, Glenn Nielsen wrote: Was this really necessary? The email below went to both the commons-dev and tomcat -dev lists. If Remy was pointing the finger at anyone, it was at his fellow Tomcat Developers. Thats how I interpreted it. Martin has been busting his tail trying to get FileUpload released so that Struts can make a full 1.1 release, and I'm sure he's just a little frustrated that other projects which have a dependency on the library aren't participating very much in the bug cleanup, or, apparently, the commons-dev mailing list where this was discussed thoroughly before the change happened. In fact, Martin was reluctant to remove the deprecated methods completely, and other developers here on commons-dev pointed out that there is no guarantee of API in unreleased software. When I read the message from Remy, I read it as a jab at FileUpload. And since Martin has basically been a one-man FileUpload team for several weeks (while being busy in his real life), he took it personally. Rereading Remy's message, I can see why Glenn read it as being spoken to the tomcat-dev list, with commons-dev as more of a 'cc'. But that's not how I read it originally. I'd think at least one committer on any major open-source project should be committed to monitoring the status of each library that project depends on -- if someone had been doing that, this would not have been a surprise. Just a bystander... Joe -- -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com If nature worked that way, the universe would crash all the time. --Jaron Lanier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] fileupload 1.0 RC 1 API breakage
The attached works for me (against commons-fileupload HEAD). I didn't do
anything about it since I wasn't sure which version of fileupload we were
targeting.
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]; Jakarta
Commons Developers List [EMAIL PROTECTED]
Sent: Wednesday, June 04, 2003 12:09 AM
Subject: [5.0] fileupload 1.0 RC 1 API breakage
FileUpload.setRepositoryPath(String) and FileItem(String) were removed
from the fileupload RC 1 release, which breaks the Tomcat 4.1.x and
5.0.x build. The first method has no apparent replacement (but I didn't
try to dig around).
This is clearly an unacceptable situation from the Tomcat perspective
:-( I'm hoping there can be positive solutions to the problem ...
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---BeginMessage---
Hi,
I'm not set up to build Tomcat, so I can't verify these changes, but I've
attached a patch that should fix the Gump breakage.
--
Martin Cooper
Craig McClanahan [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-06-02/tomcat-catalina.html
Buildfile: build.xml
flags:
flags.display:
[echo] --- Build environment for Catalina ---
[echo] If ${property_name} is displayed, then the property is not
set)
[echo] --- Build options ---
[echo] full.dist=${full.dist}
[echo] build.sysclasspath=only
[echo] compile.debug=${compile.debug}
[echo] compile.deprecation=${compile.deprecation}
[echo] compile.optimize=${compile.optimize}
[echo] --- Ant Flags ---
[echo] style task available (required)=true
[echo] --- JDK ---
[echo] jdk.1.2.present=true
[echo] jdk.1.3.present=true
[echo] jdk.1.4.present=true
[echo] --- Source Dependencies ---
[echo] jtc.home.present=true
[echo] --- Required Libraries ---
[echo] beanutils.present=true
[echo] collections.present=true
[echo] digester.present=true
[echo] jaxp.present=true
[echo] jndi.present=true
[echo] logging.present=true
[echo] regexp.present=true
[echo] servlet.present=true
[echo] --- Optional Libraries ---
[echo] daemon.present=${daemon.present}
[echo] dbcp.present=${dbcp.present}
[echo] fileupload.present=true
[echo] jaas.present=true
[echo] javamail.present=${javamail.present}
[echo] jmx.present=${jmx.present}
[echo] jsse.present=true
[echo] jta.present=${jta.present}
[echo] junit.present=${junit.present}
[echo] ldap.present=true
[echo] modeler.present=${modeler.present}
[echo] pool.present=${pool.present}
[echo] tyrex.present=${tyrex.present}
[echo] --- Required JARs ---
[echo] jndi.jar.present(except JDK 1.3+)=${jndi.jar.present}
[echo] regexp.jar.present=true
[echo] servlet.jar.present=true
[echo] xerces.jar.present(except JDK 1.4+ or
xerces2)=${xerces.jar.present}
[echo] xerces2.jars.present(except JDK 1.4+ or
xerces1)=${xerces2.jars.present}
[echo] --- Optional JARs ---
[echo] daemon.jar.present=${daemon.jar.present}
[echo] dbcp.jar.present=${dbcp.jar.present}
[echo] fileupload.jar.present=${fileupload.jar.present}
[echo] jaas.jar.present=${jaas.jar.present}
[echo] javamail.jar.present=${javamail.jar.present}
[echo] jdbc20ext.jar.present=${jdbc20ext.jar.present}
[echo] jmx.jar.present=${jmx.jar.present}
[echo] jta.jar.present=${jta.jar.present}
[echo] junit.jar.present=${junit.jar.present}
[echo] ldap.jar.present=${ldap.jar.present}
[echo] modeler.jar.present=${modeler.jar.present}
[echo] pool.jar.present=${pool.jar.present}
[echo] tyrex.jar.present=${tyrex.jar.present}
[echo] --- Conditional compilation flags ---
[echo] compile.daemon=${compile.daemon}
[echo] compile.dbcp=${compile.dbcp}
[echo] compile.jaas=true
[echo] compile.javamail=${compile.javamail}
[echo] compile.jmx=${compile.jmx}
[echo] compile.jndi=true
[echo] compile.jsse=true
[echo] compile.jta=${compile.jta}
[echo] compile.junit=${compile.junit}
[echo] compile.ldap=true
[echo] compile.ssi=true
[echo] compile.tyrex=${compile.tyrex}
[echo] --- Distribution flags ---
[echo] copy.daemon.jar=${copy.daemon.jar}
[echo] copy.dbcp.jar=${copy.dbcp.jar}
[echo] copy.jaas.jar=${copy.jaas.jar}
[echo] copy.jdbc20ext.jar=${copy.jdbc20ext.jar}
[echo] copy.javamail.jar=${copy.javamail.jar}
[echo] copy.jmx.jar=${copy.jmx.jar}
[echo] copy.jndi.jar=${copy.jndi.jar}
[echo]
Re: [5.0] fileupload 1.0 RC 1 API breakage
Martin Cooper wrote: I posted a patch to the Tomcat-Dev list yesterday which should fix this problem. Apparently, nobody on the Tomcat-Dev list paid any attention to my post. The methods in question have been deprecated for some time. I have not seen the patch email on tomcat-dev. Perhaps its in the moderator queue. BTW, use of FileUpload was implemented in Tomcat once there was a Beta release of FileUpload. So the API must have changed since the Beta release. I have gone out of my way to help FileUpload clients avoid exactly this kind of issue. It really ticks me off to see this kind of message, when I have gone to great lengths to make sure that the clients I know about are made aware of the changes before they happen. Thats great that you performed notifications to known clients. :-) Somehow Tomcat slipped through the cracks. :-( I don't recall seeing anything about this on the Tomcat list. I wlll admit that I subscribe to commons-dev but often don't keep up with messages related to the code bases there I am interested in. Get your own act together, Tomcat developers, before you start pointing the finger at those of us who really try hard to maintain compatibility across Jakarta projects. Was this really necessary? The email below went to both the commons-dev and tomcat -dev lists. If Remy was pointing the finger at anyone, it was at his fellow Tomcat Developers. Thats how I interpreted it. We (tomcat devs) will fix use of FileUpload in Tomcat and move on, no big deal. Regards, Glenn -- Martin Cooper On Wed, 4 Jun 2003, Remy Maucherat wrote: FileUpload.setRepositoryPath(String) and FileItem(String) were removed from the fileupload RC 1 release, which breaks the Tomcat 4.1.x and 5.0.x build. The first method has no apparent replacement (but I didn't try to dig around). This is clearly an unacceptable situation from the Tomcat perspective :-( I'm hoping there can be positive solutions to the problem ... Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
