Hi,
We have few bugs fixed that require a speedy release, so I'll tag
1.0.14 later today and push for a release process.
Regards
--
^TM
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-ma
Hi Gary,
there's also new guy in the town, which is called Airline[1], that
supports the Git like commands structures. I am JCommander user as
well but in one of the last projects I plugged Airline and I really
liked it - the Help command is really straightforward! :)
Just to say what's the state
Am 06.03.2013 13:35, schrieb sebb:
On 6 March 2013 11:32, Benedikt Ritter wrote:
Hi,
I have recently learned that changing the required Java version for a
component does not necessarily affect binary compartibility [1].
I'm thinking about updating [BeanUtils] to Java 1.5. We would have the
fol
2013/3/6 sebb :
> There are yet more broken links on the commons site for all components.
>
> Most of the stuff below "Project Reports" is broken; the only links
> that aren't are the external ones, i.e. those that don't point to
> commons.apache.org.
>
> This is presumably because the components a
No objections have been shown, I applied the patch at r1453464
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Wed, Mar 6, 2013 at 10:51 AM, Simone Tripodi
wrote:
> Hi all,
>
> I just recorder FILEUPLOAD-2
On 6 March 2013 16:30, sebb wrote:
> There are yet more broken links on the commons site for all components.
>
> Most of the stuff below "Project Reports" is broken; the only links
> that aren't are the external ones, i.e. those that don't point to
> commons.apache.org.
>
> This is presumably beca
There are yet more broken links on the commons site for all components.
Most of the stuff below "Project Reports" is broken; the only links
that aren't are the external ones, i.e. those that don't point to
commons.apache.org.
This is presumably because the components are now under proper/ rather
Hi all mates,
I am going to drop the 'tasks' page[1] since TODOs are tracked in JIRA.
Before I go ahead, does anyone have a reason why it should be kept?
TIA,
-Simo
[1] http://commons.apache.org/proper/commons-fileupload/tasks.html
http://people.apache.org/~simonetripodi/
http://simonetripodi.li
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
On 5 March 2013 22:28, Lawrence Angrave wrote:
> Hi,
Thanks for the feedback.
> Some comments that are relevant to Apache3 UnicodeEscaper and Apache2's
> StringEscapeUtils.java
> Summary-
>
> * I noticed the current Apache code creates three String objects each
>time it writes a unicode he
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
Hi,
Some comments that are relevant to Apache3 UnicodeEscaper and Apache2's
StringEscapeUtils.java
Summary-
* I noticed the current Apache code creates three String objects each
time it writes a unicode hexadecimal value.
* Apache3 can also create a char[] array per character translatio
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
On Wed, Mar 6, 2013 at 8:23 AM, Christian Grobmeier wrote:
> On Wed, Mar 6, 2013 at 1:01 PM, Gary Gregory
> wrote:
> > Strictly speaking, you do not need his permission AFAIK. IOW, don't
> bother
> > sending ME an email to tell me you'll moving my @author to pom.xml ;)
>
> Out of interest, are yo
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 Wed, Mar 6, 2013 at 1:01 PM, Gary Gregory wrote:
> Strictly speaking, you do not need his permission AFAIK. IOW, don't bother
> sending ME an email to tell me you'll moving my @author to pom.xml ;)
Out of interest, are you sure there is no permission needed? I am
thinking on another project wh
Yes I know. but if Craig has created a lot of the code I find it
appropriate to ask him. I'll let you know what he answered :)
Benedikt
2013/3/6 Gary Gregory
> Strictly speaking, you do not need his permission AFAIK. IOW, don't bother
> sending ME an email to tell me you'll moving my @author t
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.
On 6 March 2013 11:32, Benedikt Ritter wrote:
> Hi,
>
> I have recently learned that changing the required Java version for a
> component does not necessarily affect binary compartibility [1].
> I'm thinking about updating [BeanUtils] to Java 1.5. We would have the
> following advantages:
>
> - co
Strictly speaking, you do not need his permission AFAIK. IOW, don't bother
sending ME an email to tell me you'll moving my @author to pom.xml ;)
Gary
Gary
On Wed, Mar 6, 2013 at 2:50 AM, Benedikt Ritter wrote:
> Thanks for your comments. I have create BEANUTILS-431 [1]. Since Craig
> McClanaha
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()
+1
Gary
On Mar 6, 2013, at 6:33, Benedikt Ritter wrote:
> Hi,
>
> I have recently learned that changing the required Java version for a
> component does not necessarily affect binary compartibility [1].
> I'm thinking about updating [BeanUtils] to Java 1.5. We would have the
> following advanta
Hi,
I have recently learned that changing the required Java version for a
component does not necessarily affect binary compartibility [1].
I'm thinking about updating [BeanUtils] to Java 1.5. We would have the
following advantages:
- concurrency facilities in java.util.concurrent (could be useful
CVE-2013-0248 Apache Commons FileUpload - Insecure examples
Severity: Low
Vendor: The Apache Software Foundation
Versions Affected:
- Commons FileUpload 1.0 to 1.2.2
Description:
Commons FileUpload provides file upload capability for Servlets and web
applications. During the upload process, Fil
On Wed, Mar 6, 2013 at 11:22 AM, sebb wrote:
> I fixed the 3 @since 1.3 markers.
great, thanks! :)
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
-
I fixed the 3 @since 1.3 markers.
On 6 March 2013 09:57, sebb wrote:
> I've added some tags.
>
> Looks like the files were added in 1.2.1; this was in r523066
>
> I expect it was intended that the next release would be 1.3, but for
> some reason a point release was made.
>
> Normally Commons comp
Hey Simo,
I meant search the changes report build from trunk. :) Features added after
1.2.1 should be listed there.
Benedikt
2013/3/6 sebb
> Same applies to the FileItemHeadersImpl class.
>
> On 6 March 2013 09:57, sebb wrote:
> > I've added some tags.
> >
> > Looks like the files were added
Same applies to the FileItemHeadersImpl class.
On 6 March 2013 09:57, sebb wrote:
> I've added some tags.
>
> Looks like the files were added in 1.2.1; this was in r523066
>
> I expect it was intended that the next release would be 1.3, but for
> some reason a point release was made.
>
> Normally
I've added some tags.
Looks like the files were added in 1.2.1; this was in r523066
I expect it was intended that the next release would be 1.3, but for
some reason a point release was made.
Normally Commons components bump the minor release for the next
version (I assume this is the default for
Hi all,
I just recorder FILEUPLOAD-225 with a patch proposal.
If there are not objection, I am going to commit it.
TIA!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
-
One way to do this is to add SVN tag markers - Eclipse then shows
these in the SVN History list.
On 6 March 2013 09:20, Simone Tripodi wrote:
> A dummy search on changes-report[1] doesn't show up anything useful -
> I'll dig later after some work is already done
>
> danke
> -Simo
>
> [1] http://c
>> 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
A dummy search on changes-report[1] doesn't show up anything useful -
I'll dig later after some work is already done
danke
-Simo
[1] http://commons.apache.org/proper/commons-fileupload/changes-report.html
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitt
Hi Simo,
have you looked at the changes report?
Benedikt
2013/3/6 Simone Tripodi
> same for FileItemHeaders, looks to me that they were contributed in
> the same patch
>
> TIA,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/si
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.
On 6 March 2013 06:49, Lukasz Lenart wrote:
> Hi,
>
> I was checking out what should be solved before releasing a new
> version and in my opinion most of PMD [1] errors can be omitted, maybe
> "These nested if statements could be combined" should be resolved, but
> the rest I don't see a point ins
>> 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
same for FileItemHeaders, looks to me that they were contributed in
the same patch
TIA,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Wed, Mar 6, 2013 at 9:43 AM, Simone Tripodi wrote:
> Hi all,
>
Hi all,
FileItemHeadersSupport has a wrong @since tag, which targets 1.3 -
which looks a future release.
Before I start to dig in commit list, does someone already has an idea
when the interface was introduced? :)
TIA :P
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejo
Hi,
I'd like to close LOGGING-149 [1] for 1.1.2. It's just about the
documentation regarding OSGi support on our website [2]. Comments are
appreciated.
Benedikt
[1] https://issues.apache.org/jira/browse/LOGGING-149
[2] http://wiki.apache.org/commons/Logging/FrequentlyAskedQuestions
--
http://p
41 matches
Mail list logo
