Elliot Metsger wrote:
David,
I looked at the Gump output a week or so ago...
[javac]
/x1/gump/public/workspace/portals-pluto-1.0/portal/src/java/org/apache/commons/fileupload/PortletFileUploadBase.java:290:
cannot find symbol
[javac] symbol : constructor
MultipartStream(java.io.InputStream,byte[])
[javac] location: class org.apache.commons.fileupload.MultipartStream
[javac] MultipartStream multi = new
MultipartStream(input, boundary);
It looks like a problem with the commons-fileupload dependency?
Pluto Portal depends on commons-fileupload 1.0. The commons-fileupload
trunk has removed the MultipartStream(java.io.InputStream,byte[])
constructor in r429098 [0]. As it stands, Pluto Portal won't be able to
compile against commons-fileupload 1.2 when it is released.
It isn't clear to me (because I'm not familiar with Gump) - is Gump
building the 1.0.1 tag or are they pulling the 1.0.2 branch?
Per the gump metadata [1], gump is building the pluto 1.0.2 branch. It
also appears to be building commons-fileupload trunk.
As far as
I know there's nothing that has been done in the 1.0.2 branch that would
cause this (but I've been wrong before)
See above. The build fails due to a change in the commons-fileupload
MultipartStream class.
I can take responsibility for looking into this and figgurin' this one
out, seeing has how I've been the one messing around with 1.0.2 lately.
How should we handle this? Update pluto's dependency to
commons-fileupload 1.0.2-SNAPSHOT? Make pluto work with both
commons-fileupload 1.0 and 1.2? Ignore it?
Thanks for the advice,
Elliot
[0] svn diff -r 429097:429098
https://svn.apache.org/repos/asf/jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java
[1] http://svn.apache.org/repos/asf/gump/metadata/project/portals-pluto.xml