Hi Simo
Thanks for confirming. Very much appreciated.
Regards
Felix
Am 06.03.2013 um 16:16 schrieb Simone Tripodi:
Hi Felix!
indeed, we are putting effort on NOT breaking the backwards
compatibility with 1.2.X, we updated to version 1.3 - due to some APIs
update - and I personally
Is there anybody that can suggest how to handle that situation?
Create new methods which return long rather than int; deprecate the old
methods.
e.g.
@Deprecated
public int getContentLength() { ... }
/**
* @since x.x
*/
public long getLongContentLength() { ... }
or
public long
On 6 March 2013 08:53, Simone Tripodi simonetrip...@apache.org wrote:
Is there anybody that can suggest how to handle that situation?
Create new methods which return long rather than int; deprecate the old
methods.
e.g.
@Deprecated
public int getContentLength() { ... }
/**
* @since
that should be enough to bump to 1.3.0 since there are APIs addition -
do you agree?
Yes, except it should be 1.3, not 1.3.0.
If a point release is then required, it is 1.3.1, but point releases
are fairly rare.
OK thanks :)
http://people.apache.org/~simonetripodi/
2013/3/6 sebb seb...@gmail.com
On 6 March 2013 08:53, Simone Tripodi simonetrip...@apache.org wrote:
Is there anybody that can suggest how to handle that situation?
Create new methods which return long rather than int; deprecate the old
methods.
e.g.
@Deprecated
public int
On 6 March 2013 11:51, Benedikt Ritter brit...@apache.org wrote:
2013/3/6 sebb seb...@gmail.com
On 6 March 2013 08:53, Simone Tripodi simonetrip...@apache.org wrote:
Is there anybody that can suggest how to handle that situation?
Create new methods which return long rather than int;
Hi,
Am 06.03.2013 um 12:51 schrieb Benedikt Ritter:
2013/3/6 sebb seb...@gmail.com
On 6 March 2013 08:53, Simone Tripodi simonetrip...@apache.org wrote:
Is there anybody that can suggest how to handle that situation?
Create new methods which return long rather than int; deprecate the old
2013/3/6 Felix Meschberger fmesc...@adobe.com
Hi,
Am 06.03.2013 um 12:51 schrieb Benedikt Ritter:
2013/3/6 sebb seb...@gmail.com
On 6 March 2013 08:53, Simone Tripodi simonetrip...@apache.org wrote:
Is there anybody that can suggest how to handle that situation?
Create new methods
And, just for the sake of putting more steaks on the barbeque, the
bundle-plugin takes care of adjusting the version in the MANIFEST.MF
according to the SemVer recommendations; version is now 1.3-SNAPSHOT
and look below how the MANIFEST.MF has been generated.
alles gute!
-Simo
$ cat
Hi,
Am 06.03.2013 um 14:56 schrieb Simone Tripodi:
And, just for the sake of putting more steaks on the barbeque, the
bundle-plugin takes care of adjusting the version in the MANIFEST.MF
according to the SemVer recommendations; version is now 1.3-SNAPSHOT
and look below how the MANIFEST.MF
Hi Felix!
indeed, we are putting effort on NOT breaking the backwards
compatibility with 1.2.X, we updated to version 1.3 - due to some APIs
update - and I personally planned to cut the next release keeping that
version, so projects like Struts, Sling, ... could adopt it without
feeling pain :)
Dear all!
I've finished my patch for 2Gb+ uploads.
Since I don't use portlets, it needs some additional fix for portlets (it's
not broken, just returns -1 as the total size of the file, when it's over
2Gb.
Gergo
see
Hi Gergo,
I've finished my patch for 2Gb+ uploads.
Since I don't use portlets, it needs some additional fix for portlets (it's
not broken, just returns -1 as the total size of the file, when it's over
2Gb.
Gergo
very good, thanks, since I am doing some work on [fileupload], I am
reviewing
Hi again Gergo,
patch looks OK to me, the problem we would have ATM is the backward
compatibility, since there methods signature change.
Is there anybody that can suggest how to handle that situation?
TIA,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
On 5 March 2013 15:46, Simone Tripodi simonetrip...@apache.org wrote:
Hi again Gergo,
patch looks OK to me, the problem we would have ATM is the backward
compatibility, since there methods signature change.
Is there anybody that can suggest how to handle that situation?
Create new methods
2 more questions:
1. Could I compile just the fileupload project (at my first attempt, it
complains about missing parent pom.xml)
2. Is the svn repository at
http://svn.apache.org/viewvc/commons/proper/fileupload/trunk/
I am behind a corporate proxy, so I'm not sure about these things. For 2. I
Hi all!
As I find my concrete issue in the JIRA here:
https://issues.apache.org/jira/browse/FILEUPLOAD-195#comment-13589406 I
have a new question:
I am ready to fix this problem, and I would like to contribute the result
to the community.
But first, IS THERE ANYBODY FIXING 2GB UPLOAD LIMIT
Hello Gergely,
2013/3/1 KONTRA, Gergely pihent...@gmail.com
Hi all!
As I find my concrete issue in the JIRA here:
https://issues.apache.org/jira/browse/FILEUPLOAD-195#comment-13589406 I
have a new question:
I am ready to fix this problem, and I would like to contribute the result
to the
On Fri, Mar 1, 2013 at 5:06 PM, Benedikt Ritter brit...@apache.org wrote:
Sorry, but the github mirrors are read only (AFAIK). Usually contributions
are made through SVN diff files uploaded to Jira. Would it be possible for
you to upload an SVN diff to jira? Don't forget to add some unit tests
On 01/03/2013 08:41, KONTRA, Gergely wrote:
On Fri, Mar 1, 2013 at 5:06 PM, Benedikt Ritter brit...@apache.org wrote:
Sorry, but the github mirrors are read only (AFAIK). Usually contributions
are made through SVN diff files uploaded to Jira. Would it be possible for
you to upload an SVN diff
20 matches
Mail list logo
