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 pl
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 :)
T
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.M
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 target/osgi/M
2013/3/6 Felix Meschberger
> Hi,
>
> Am 06.03.2013 um 12:51 schrieb Benedikt Ritter:
>
> > 2013/3/6 sebb
> >
> >> On 6 March 2013 08:53, Simone Tripodi wrote:
> > Is there anybody that can suggest how to handle that situation?
>
> Create new methods which return long rather than i
Hi,
Am 06.03.2013 um 12:51 schrieb Benedikt Ritter:
> 2013/3/6 sebb
>
>> On 6 March 2013 08:53, Simone Tripodi 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.
On 6 March 2013 11:51, Benedikt Ritter wrote:
> 2013/3/6 sebb
>
>> On 6 March 2013 08:53, Simone Tripodi 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.
2013/3/6 sebb
> On 6 March 2013 08:53, Simone Tripodi 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()
>> 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/
http://simonetrip
On 6 March 2013 08:53, Simone Tripodi 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 x.
>> 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
On 5 March 2013 15:46, Simone Tripodi 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 which return long ra
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/
http:
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
revie
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
https://github.com/pihentagy/commons-fileupload/commit/16a677dd3c61acde530a5f54a
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
g
On 01/03/2013 08:41, KONTRA, Gergely wrote:
On Fri, Mar 1, 2013 at 5:06 PM, Benedikt Ritter 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 forg
On Fri, Mar 1, 2013 at 5:06 PM, Benedikt Ritter 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 ;-)
>
Yep, git
Hello Gergely,
2013/3/1 KONTRA, Gergely
> 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.
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 SILEN
20 matches
Mail list logo
