commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <mart...@apache.org>
Subject RE: Recent change to FileUpload's DefaultFileItem
Date Wed, 30 Apr 2003 15:50:57 GMT


On Wed, 30 Apr 2003, Howard M. Lewis Ship wrote:

>
> http://cvs.apache.org/viewcvs/jakarta-commons/fileupload/src/java/org/apache
> /commons/fileupload/DefaultFileItem.java.diff?r1=1.16&r2=1.17&diff_format=h
>
> Tapestry uses the DefaultFileItem.getStoreLocation() method, which has been
> removed.

That method was not removed - it is still there, with the same signature -
so there must be something else that's causing a breakage.

>
> Changing Tapestry is not a big deal, except then the Tapestry code would be
> dependent on the alpha FileUpload code, rather than the GA FileUploade code
> bundled with the Tapestry distro.  That's where the Gump discussion is going
> ...

Well, Gump's purpose in life is not to build the distributions, but to
keep building HEAD of everything against HEAD of everything else,
precisely so that we can identify issues like this one outside of the
official distributions. That being the case, I don't see an issue with
Tapestry's HEAD relying on FileUpload's HEAD unless there is an imminent
new release of Tapestry in the wings.

As a point of reference, Struts is in a similar position. We (putting my
Struts hat on for brevity ;) rely on a number of Commons components, and
our nightly builds are built against the respective Commons nightlies. As
such, we are liable to the same breakage as Tapestry in the nightlies. Of
course, any final release of Struts would depend only on final releases of
the corresponding Commons components.

--
Martin Cooper


>
> Anyway, one solution is to make the change to DefaultFileItem less severe,
> by deprecating the method instead of removing it outright.
>
> The other solution is for Tapestry to compile against the 1.0-beta-1
> distributed with the framework.
>
> --
> Howard M. Lewis Ship
> Creator, Tapestry: Java Web Components
> http://jakarta.apache.org/tapestry
>
>
>
> > -----Original Message-----
> > From: news [mailto:news@main.gmane.org] On Behalf Of Martin Cooper
> > Sent: Tuesday, April 29, 2003 5:57 PM
> > To: commons-dev@jakarta.apache.org
> > Subject: Re: Recent change to FileUpload's DefaultFileItem
> >
> >
> > If you could let us know which particular change is causing
> > the problem, we'll see what we can do about it. It should be
> > straightforward to resolve.
> >
> > --
> > Martin Cooper
> >
> >
> > "Howard M. Lewis Ship" <hlship@attbi.com> wrote in message
> > news:005d01c30e91$edefac20$6601a8c0@ALMIGHTYBEAST...
> > The change to DefaultFileItem has broken Tapestry.
> >
> > This has sparked a debate on the Gump list about whether
> > compilation against latest source is such a great idea.  The
> > gist of it is that Gump is supposed
> > to "spark communication between projects".   Tapestry uses
> > FileUpload, and
> > since Gump compiles Tapestry HEAD against FileUpload head,
> > the API change has broken Tapestry's build.
> >
> > In the meantime, I'm curious about whether the change to
> > DefaultFileItem can be reversed, or accomplished in a more
> > backwards-compatible way.
> >
> > --
> > Howard M. Lewis Ship
> > Creator, Tapestry: Java Web Components
> > http://jakarta.apache.org/tapestry
> >
> >
> >
> > > -----Original Message-----
> > > From: Howard M. Lewis Ship [mailto:hlship@attbi.com]
> > > Sent: Tuesday, April 29, 2003 9:39 AM
> > > To: Jakarta Gump
> > > Subject: Dependencies out of control
> > >
> > >
> > > Here's a Gump question for ya (or maybe I'm missing something).
> > >
> > > Gump compiles my code (Tapestry) against the very latest
> > and greatest
> > > (alpha) code of all of Tapestry's dependencies.
> > >
> > > A change in commons FileUpload has broken Tapestry.  The
> > interface of
> > > a class has changed due to some refactoring.
> > >
> > > Now, I could change Tapestry to reflect the FileUpload change, but
> > > that would mean that Tapestry would no longer compile against the
> > > bundled (lets just call it "release
> > > frozen") copy of FileUpload that is distributed with
> > Tapestry.  This
> > > copy is the most recent GA copy of FileUtils.
> > >
> > > At deployment time, this will force someone who deploys the next
> > > relesae of Tapestry (a stable beta) to also HAVE TO deploy
> > an unstable
> > > alpha of FileUpload.
> > >
> > > This wouldn't be a problem if FileUpload and Tapestry were
> > in absolute
> > > lock-step on releases, but that is not realistic.
> > >
> > > I'm going to change my gump.xml to reference my bundled copy of
> > > FileUtils, rather than the Gump latest-and-greatest.  If FileUtils
> > > goes GA before Tapestry, I'll change my Tapestry code and
> > change the
> > > gump.xml back.
> > >
> > > --
> > > Howard M. Lewis Ship
> > > Creator, Tapestry: Java Web Components
> > > http://jakarta.apache.org/tapestry
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Howard M.Lewis Ship [mailto:hlship@apache.org]
> > > > Sent: Tuesday, April 29, 2003 7:55 AM
> > > > To: tapestry-dev@jakarta.apache.org
> > > > Subject: [GUMP] Build Failure - jakarta-tapestry
> > > >
> > > >
> > > > ----------------------------------------------------
> > > > This email is autogenerated from the output from:
> > > >
> > <http://cvs.apache.org/builds/gump/2003-04-29/jakarta-tapestry.html>
> > > > ----------------------------------------------------
> > > >
> > > > Buildfile: build.xml
> > > >
> > > > check-for-jboss-dir:
> > > >
> > > > check-for-jetty-dir:
> > > >
> > > > install:
> > > >
> > > > init:
> > > >     [mkdir] Created dir:
> > > > /home/rubys/jakarta/jakarta-tapestry/framework/classes
> > > >
> > > > compile:
> > > >     [javac] Compiling 403 source files to
> > > > /home/rubys/jakarta/jakarta-tapestry/framework/classes
> > > >     [javac]
> > > > /home/rubys/jakarta/jakarta-tapestry/framework/src/org/apache/
> > > > tapestry/multipart/UploadPart.java:101: cannot resolve symbol
> > > >     [javac] symbol  : method newInstance
> > > > (java.lang.String,java.lang.String,java.lang.String,int,int)
> > > >     [javac] location: class
> > > > org.apache.commons.fileupload.DefaultFileItem
> > > >     [javac]             DefaultFileItem.newInstance(path,
> > > > name, contentType, requestSize, threshold);
> > > >     [javac]                            ^
> > > >     [javac]
> > > > /home/rubys/jakarta/jakarta-tapestry/framework/src/org/apache/
> > > > tapestry/multipart/UploadPart.java:148: cannot resolve symbol
> > > >     [javac] symbol  : method getStoreLocation ()
> > > >     [javac] location: interface
> > > org.apache.commons.fileupload.FileItem
> > > >     [javac]                     _fileItem.getStoreLocation()),
> > > >     [javac]                              ^
> > > >     [javac]
> > > > /home/rubys/jakarta/jakarta-tapestry/framework/src/org/apache/
> > > > tapestry/multipart/UploadPart.java:165: cannot resolve symbol
> > > >     [javac] symbol  : method getStoreLocation ()
> > > >     [javac] location: interface
> > > org.apache.commons.fileupload.FileItem
> > > >     [javac]         File file = _fileItem.getStoreLocation();
> > > >     [javac]                              ^
> > > >     [javac] Note: Some input files use or override a
> > deprecated API.
> > > >     [javac] Note: Recompile with -deprecation for details.
> > > >     [javac] 3 errors
> > > >
> > > > BUILD FAILED
> > > > /home/rubys/jakarta/jakarta-tapestry/framework/build.xml:29:
> > > > Compile failed; see the compiler error output for details.
> > > >
> > > > Total time: 23 seconds
> > > >
> > > >
> > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > tapestry-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> > > tapestry-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: gump-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: gump-help@jakarta.apache.org
> > >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message