[VOTE][RESULT] Release Apache Commons File Upload 1.3.1 RC1 as 1.3.1
The following votes were cast: Binding: +1: ebourg, luc, markt, britter, ggregory, bodewig No other votes were cast. The vote therefore passes. Thank you to everyone who tested and voted in a shorter than usual time frame. I'll do the actual release shortly. Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LANG] Towards 3.3
On 31 January 2014 07:54, Benedikt Ritter brit...@apache.org wrote: Nice discussion. Thanks for clearing this up. So Duncan: go ahead if you got the time. Hi Benedikt, Based on other discussions on the ML, the fix for LANG-341 belongs in the Conversion class. I think this warrants a larger piece of work to implement some of the missing methods in that class. I therefore suggest that LANG-341 should be ignored for 3.3 and shouldn't hold up your plans to release. Duncan 2014/1/31 Duncan Jones dun...@wortharead.com On 31 January 2014 04:37, Henri Yandell flame...@gmail.com wrote: Read section 5 of the license. Ok, that's pretty clear-cut then. To save others from dragging up the wording: 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. So I'd say any patch to existing source would be covered by that. The term Contribution is defined higher in the license and includes submission to the issue tracking system. Obtaining an ICLA should still be a goal, I think, but it shouldn't prevent us from adding useful patches to the project. Duncan On Jan 30, 2014 10:16 AM, Benedikt Ritter brit...@apache.org wrote: I'm not sure whether providing a patch for an AL licensed file is automatically licensed under AL as well. In the end the raw diff file does not contain the AL header, so you're better of with an ICLA. Benedikt 2014/1/27 Henri Yandell flame...@gmail.com Depends whose arguing probably :) Our license gives us a right to contributions under Apache 2.0 unless stated otherwise; the ICLA is playing safer. We can also simply take anything under a compatible license and include (with suitable licensing). I did that for a method from Spring. Hen On Sun, Jan 26, 2014 at 1:31 PM, Duncan Jones dun...@wortharead.com wrote: On 26 January 2014 19:47, Duncan Jones dun...@wortharead.com wrote: On 26 January 2014 18:49, Benedikt Ritter brit...@apache.org wrote: Hi Duncan, 2014/1/26 Duncan Jones dun...@wortharead.com On 26 January 2014 13:33, Benedikt Ritter brit...@apache.org wrote: Hi all, we've fixed some bugs and we have some nice new features implemented (DiffBuilder, Jaro-Winkler Distance, RandomUtils, ClassPathUtils), so I'm planning to cut a RC in the first week of February. I just wanted to know if there is anything you'd like to have included in the next release. Then please tag it with fix version 3.3. Regards, Benedikt I'm debating whether LANG-341 might be a candidate for inclusion. The patch is fairly complete, just needs Javadocs and a couple of additional unit tests, which I can sort over the coming week. What do you guys think? It seems like a useful addition to me. Yes looks neat. The problem I'm seeing is, that the last activity is from Nov 2011, and the contributor has no ICLA listed (see [1]), so IP is not absolutely clear. I'm unsure if we can use this contribution without the ICLA. Anyway, Hen has contributed the patch Vincent Ricard used, so we can use Hen's patch and improve it. Benedikt [1] http://people.apache.org/committer-index.html#unlistedclas Good point. I think in this case I'll ping the contributor to get their thoughts on an ICLA and assume this will miss v3.3. He's done a lot of work to extend Hen's patch and it would be a shame for that not to get committed if he's interested. If there's no reply (or no interest), I'll sort something for v3.4. Having said that... does this still represent a problem if the contributor has patched existing code (containing the Apache license)? Are there any situations where we can take a patch and apply it to trunk without the contributor having an ICLA? I certainly had patches applied in the past without an ICLA, but perhaps things were more lax then? Duncan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://people.apache.org/~britter/
Re: [fileupload] file stream leaks?
Any chance to convert them using try-with-resource statements in future, I
guess that will make code much cleaner.
On Fri, Feb 7, 2014 at 1:02 AM, Gary Gregory garydgreg...@gmail.com wrote:
On Thu, Feb 6, 2014 at 11:23 AM, sebb seb...@gmail.com wrote:
On 6 February 2014 16:06, Gary Gregory garydgreg...@gmail.com wrote:
On Thu, Feb 6, 2014 at 10:18 AM, sebb seb...@gmail.com wrote:
On 6 February 2014 15:04, Gary Gregory garydgreg...@gmail.com
wrote:
On Thu, Feb 6, 2014 at 9:04 AM, sebb seb...@gmail.com wrote:
On 6 February 2014 13:53, Gary Gregory garydgreg...@gmail.com
wrote:
Looking at code like DiskFileItem:684:
FileInputStream input = new
FileInputStream(dfosFile);
IOUtils.copy(input, output);
Why is this not:
FileInputStream input = new
FileInputStream(dfosFile);
try {
IOUtils.copy(input, output);
} finally {
input.close();
}
?
Oversight?
The local Streams.copy() methods do close input and optionally
output.
Maybe it was thought IO did the same?
The close should perhaps be
IOUtils.closeQuietly()
Are we interested in knowibg about input close() failures?
Good question. I would guess 'yes'. If you write to a file and then
cannot
close it, you might not have flushed it, so the file could be
corrupt?
But this is an _input_ file.
Are we interested in close failure once the copy has completed?
I would say no. BUT... if you replace the Streams code with:
public static long copy(InputStream inputStream, OutputStream
outputStream, boolean closeOutputStream, byte[] buffer)
throws IOException {
try {
return IOUtils.copy(inputStream, outputStream);
} finally {
IOUtils.closeQuietly(inputStream);
if (closeOutputStream) {
IOUtils.closeQuietly(outputStream);
}
}
}
You will get an NPE in IOUtils.copy(inputStream, outputStream).
Because in some cases [fileupload] calls Streams.copy with a null
output
stream. The Javadoc for IOUtils.copy states that this is grounds for an
NPE.
So that's a no-go. I wonder if we should propose to make IOUtils.copy
ignore null output to accommodate this scenario?
No.
Change of API behaviour and allowing null will probably hide some bugs.
However, Streams could potentially call IOUtils.
Streams now reuses IOUtils.closeQuietly().
Gary
Gary
Gary
Gary
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
http://www.manning.com/bauer3/
JUnit in Action, Second Edition
http://www.manning.com/tahchiev/
Spring Batch in Action http://www.manning.com/templier/
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
http://www.manning.com/bauer3/
JUnit in Action, Second Edition http://www.manning.com/tahchiev/
Spring Batch in Action http://www.manning.com/templier/
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
http://www.manning.com/bauer3/
JUnit in Action, Second Edition http://www.manning.com/tahchiev/
Spring Batch in Action http://www.manning.com/templier/
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
http://www.manning.com/bauer3/
JUnit in Action, Second Edition http://www.manning.com/tahchiev/
Spring Batch in Action http://www.manning.com/templier/
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
--
Thanks
Javin
http://javarevisited.blogspot.com/
Re: [LANG] Towards 3.3
2014-02-07 Duncan Jones dun...@wortharead.com: On 31 January 2014 07:54, Benedikt Ritter brit...@apache.org wrote: Nice discussion. Thanks for clearing this up. So Duncan: go ahead if you got the time. Hi Benedikt, Based on other discussions on the ML, the fix for LANG-341 belongs in the Conversion class. I think this warrants a larger piece of work to implement some of the missing methods in that class. I therefore suggest that LANG-341 should be ignored for 3.3 and shouldn't hold up your plans to release. Okay, I've set the fix version of LANG-341 to 3.x. Benedikt Duncan 2014/1/31 Duncan Jones dun...@wortharead.com On 31 January 2014 04:37, Henri Yandell flame...@gmail.com wrote: Read section 5 of the license. Ok, that's pretty clear-cut then. To save others from dragging up the wording: 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. So I'd say any patch to existing source would be covered by that. The term Contribution is defined higher in the license and includes submission to the issue tracking system. Obtaining an ICLA should still be a goal, I think, but it shouldn't prevent us from adding useful patches to the project. Duncan On Jan 30, 2014 10:16 AM, Benedikt Ritter brit...@apache.org wrote: I'm not sure whether providing a patch for an AL licensed file is automatically licensed under AL as well. In the end the raw diff file does not contain the AL header, so you're better of with an ICLA. Benedikt 2014/1/27 Henri Yandell flame...@gmail.com Depends whose arguing probably :) Our license gives us a right to contributions under Apache 2.0 unless stated otherwise; the ICLA is playing safer. We can also simply take anything under a compatible license and include (with suitable licensing). I did that for a method from Spring. Hen On Sun, Jan 26, 2014 at 1:31 PM, Duncan Jones dun...@wortharead.com wrote: On 26 January 2014 19:47, Duncan Jones dun...@wortharead.com wrote: On 26 January 2014 18:49, Benedikt Ritter brit...@apache.org wrote: Hi Duncan, 2014/1/26 Duncan Jones dun...@wortharead.com On 26 January 2014 13:33, Benedikt Ritter brit...@apache.org wrote: Hi all, we've fixed some bugs and we have some nice new features implemented (DiffBuilder, Jaro-Winkler Distance, RandomUtils, ClassPathUtils), so I'm planning to cut a RC in the first week of February. I just wanted to know if there is anything you'd like to have included in the next release. Then please tag it with fix version 3.3. Regards, Benedikt I'm debating whether LANG-341 might be a candidate for inclusion. The patch is fairly complete, just needs Javadocs and a couple of additional unit tests, which I can sort over the coming week. What do you guys think? It seems like a useful addition to me. Yes looks neat. The problem I'm seeing is, that the last activity is from Nov 2011, and the contributor has no ICLA listed (see [1]), so IP is not absolutely clear. I'm unsure if we can use this contribution without the ICLA. Anyway, Hen has contributed the patch Vincent Ricard used, so we can use Hen's patch and improve it. Benedikt [1] http://people.apache.org/committer-index.html#unlistedclas Good point. I think in this case I'll ping the contributor to get their thoughts on an ICLA and assume this will miss v3.3. He's done a lot of work to extend Hen's patch and it would be a shame for that not to get committed if he's interested. If there's no reply (or no interest), I'll sort something for v3.4. Having said that... does this still represent a problem if the contributor has patched existing code (containing the Apache license)? Are there any situations where we can take a patch and apply it to trunk without the contributor having an ICLA? I certainly had patches applied in the past without an ICLA, but perhaps things were more lax then? Duncan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Re: [fileupload] file stream leaks?
Not until the base requirement is Java 7. It's 5 now.
Gary
Original message
From: Javin Paul savingfu...@gmail.com
Date:02/07/2014 07:14 (GMT-05:00)
To: Commons Developers List dev@commons.apache.org
Subject: Re: [fileupload] file stream leaks?
Any chance to convert them using try-with-resource statements in future, I
guess that will make code much cleaner.
On Fri, Feb 7, 2014 at 1:02 AM, Gary Gregory garydgreg...@gmail.com wrote:
On Thu, Feb 6, 2014 at 11:23 AM, sebb seb...@gmail.com wrote:
On 6 February 2014 16:06, Gary Gregory garydgreg...@gmail.com wrote:
On Thu, Feb 6, 2014 at 10:18 AM, sebb seb...@gmail.com wrote:
On 6 February 2014 15:04, Gary Gregory garydgreg...@gmail.com
wrote:
On Thu, Feb 6, 2014 at 9:04 AM, sebb seb...@gmail.com wrote:
On 6 February 2014 13:53, Gary Gregory garydgreg...@gmail.com
wrote:
Looking at code like DiskFileItem:684:
FileInputStream input = new
FileInputStream(dfosFile);
IOUtils.copy(input, output);
Why is this not:
FileInputStream input = new
FileInputStream(dfosFile);
try {
IOUtils.copy(input, output);
} finally {
input.close();
}
?
Oversight?
The local Streams.copy() methods do close input and optionally
output.
Maybe it was thought IO did the same?
The close should perhaps be
IOUtils.closeQuietly()
Are we interested in knowibg about input close() failures?
Good question. I would guess 'yes'. If you write to a file and then
cannot
close it, you might not have flushed it, so the file could be
corrupt?
But this is an _input_ file.
Are we interested in close failure once the copy has completed?
I would say no. BUT... if you replace the Streams code with:
public static long copy(InputStream inputStream, OutputStream
outputStream, boolean closeOutputStream, byte[] buffer)
throws IOException {
try {
return IOUtils.copy(inputStream, outputStream);
} finally {
IOUtils.closeQuietly(inputStream);
if (closeOutputStream) {
IOUtils.closeQuietly(outputStream);
}
}
}
You will get an NPE in IOUtils.copy(inputStream, outputStream).
Because in some cases [fileupload] calls Streams.copy with a null
output
stream. The Javadoc for IOUtils.copy states that this is grounds for an
NPE.
So that's a no-go. I wonder if we should propose to make IOUtils.copy
ignore null output to accommodate this scenario?
No.
Change of API behaviour and allowing null will probably hide some bugs.
However, Streams could potentially call IOUtils.
Streams now reuses IOUtils.closeQuietly().
Gary
Gary
Gary
Gary
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
http://www.manning.com/bauer3/
JUnit in Action, Second Edition
http://www.manning.com/tahchiev/
Spring Batch in Action http://www.manning.com/templier/
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
http://www.manning.com/bauer3/
JUnit in Action, Second Edition http://www.manning.com/tahchiev/
Spring Batch in Action http://www.manning.com/templier/
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
http://www.manning.com/bauer3/
JUnit in Action, Second Edition http://www.manning.com/tahchiev/
Spring Batch in Action http://www.manning.com/templier/
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
http://www.manning.com/bauer3/
JUnit in Action,
Re: [LANG] Towards 3.3
+1 Gary Original message From: Duncan Jones dun...@wortharead.com Date:02/07/2014 05:48 (GMT-05:00) To: Commons Developers List dev@commons.apache.org Subject: Re: [LANG] Towards 3.3 On 31 January 2014 07:54, Benedikt Ritter brit...@apache.org wrote: Nice discussion. Thanks for clearing this up. So Duncan: go ahead if you got the time. Hi Benedikt, Based on other discussions on the ML, the fix for LANG-341 belongs in the Conversion class. I think this warrants a larger piece of work to implement some of the missing methods in that class. I therefore suggest that LANG-341 should be ignored for 3.3 and shouldn't hold up your plans to release. Duncan 2014/1/31 Duncan Jones dun...@wortharead.com On 31 January 2014 04:37, Henri Yandell flame...@gmail.com wrote: Read section 5 of the license. Ok, that's pretty clear-cut then. To save others from dragging up the wording: 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. So I'd say any patch to existing source would be covered by that. The term Contribution is defined higher in the license and includes submission to the issue tracking system. Obtaining an ICLA should still be a goal, I think, but it shouldn't prevent us from adding useful patches to the project. Duncan On Jan 30, 2014 10:16 AM, Benedikt Ritter brit...@apache.org wrote: I'm not sure whether providing a patch for an AL licensed file is automatically licensed under AL as well. In the end the raw diff file does not contain the AL header, so you're better of with an ICLA. Benedikt 2014/1/27 Henri Yandell flame...@gmail.com Depends whose arguing probably :) Our license gives us a right to contributions under Apache 2.0 unless stated otherwise; the ICLA is playing safer. We can also simply take anything under a compatible license and include (with suitable licensing). I did that for a method from Spring. Hen On Sun, Jan 26, 2014 at 1:31 PM, Duncan Jones dun...@wortharead.com wrote: On 26 January 2014 19:47, Duncan Jones dun...@wortharead.com wrote: On 26 January 2014 18:49, Benedikt Ritter brit...@apache.org wrote: Hi Duncan, 2014/1/26 Duncan Jones dun...@wortharead.com On 26 January 2014 13:33, Benedikt Ritter brit...@apache.org wrote: Hi all, we've fixed some bugs and we have some nice new features implemented (DiffBuilder, Jaro-Winkler Distance, RandomUtils, ClassPathUtils), so I'm planning to cut a RC in the first week of February. I just wanted to know if there is anything you'd like to have included in the next release. Then please tag it with fix version 3.3. Regards, Benedikt I'm debating whether LANG-341 might be a candidate for inclusion. The patch is fairly complete, just needs Javadocs and a couple of additional unit tests, which I can sort over the coming week. What do you guys think? It seems like a useful addition to me. Yes looks neat. The problem I'm seeing is, that the last activity is from Nov 2011, and the contributor has no ICLA listed (see [1]), so IP is not absolutely clear. I'm unsure if we can use this contribution without the ICLA. Anyway, Hen has contributed the patch Vincent Ricard used, so we can use Hen's patch and improve it. Benedikt [1] http://people.apache.org/committer-index.html#unlistedclas Good point. I think in this case I'll ping the contributor to get their thoughts on an ICLA and assume this will miss v3.3. He's done a lot of work to extend Hen's patch and it would be a shame for that not to get committed if he's interested. If there's no reply (or no interest), I'll sort something for v3.4. Having said that... does this still represent a problem if the contributor has patched existing code (containing the Apache license)? Are there any situations where we can take a patch and apply it to trunk without the contributor having an ICLA? I certainly had patches applied in the past without an ICLA, but perhaps things were more lax then? Duncan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter -
[ANNOUNCE][SECURITY] Apache Commons FileUpload 1.3.1 released
The Apache Commons Team is pleased to announce the release of Apache Commons FileUpload 1.3.1. The Apache Commons FileUpload software library makes it easy to add robust, high-performance, file upload capability to your servlets and web applications. The release is primarily a security release to address CVE-2014-0050, a denial of service vulnerability in all previous releases. Source and binary distributions are available for download from the Apache Commons download site: http://commons.apache.org/proper/commons-fileupload/download_fileupload.cgi When downloading, please verify signatures using the KEYS file available at the above location when downloading the release. Full details of all the changes in 1.3.1 can be found in the changelog: http://commons.apache.org/proper/commons-fileupload/changes-report.html For complete information on Commons FileUpload, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Commons FileUpload website: http://commons.apache.org/proper/commons-fileupload/ Mark Thomas, on behalf of the Apache Commons community - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[CLI] Release 1.3
Hi All: Is there any reason not to release 1.3? It would be nice to flush out the trunk fixes. Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [CLI] Release 1.3
Le 07/02/2014 17:59, Gary Gregory a écrit : Is there any reason not to release 1.3? It would be nice to flush out the trunk fixes. I have to recheck the current state of the code. If I remember well the new parser was ready, but I'm not sure it has really been tested on the field. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE][RESULT] Release Apache Commons File Upload 1.3.1 RC1 as 1.3.1
Hi Mark, sorry for being late on this. I just want to point out that you did a great job when handling this issue so quickly! Oliver Am 07.02.2014 10:14, schrieb Mark Thomas: The following votes were cast: Binding: +1: ebourg, luc, markt, britter, ggregory, bodewig No other votes were cast. The vote therefore passes. Thank you to everyone who tested and voted in a shorter than usual time frame. I'll do the actual release shortly. Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Fwd: svn commit: r1565902 - in /logging/log4j/log4j2/trunk: ./ log4j-1.2-api/ log4j-api/ log4j-core/ log4j-distribution/ log4j-flume-ng/ log4j-jcl/ log4j-jmx-gui/ log4j-osgi/ log4j-osgi/core-osgi-asyn
That's been a pet peeve of mine for a while... thank you for fixing it! :) Gary -- Forwarded message -- From: nickwilli...@apache.org Date: Fri, Feb 7, 2014 at 10:29 PM Subject: svn commit: r1565902 - in /logging/log4j/log4j2/trunk: ./ log4j-1.2-api/ log4j-api/ log4j-core/ log4j-distribution/ log4j-flume-ng/ log4j-jcl/ log4j-jmx-gui/ log4j-osgi/ log4j-osgi/core-osgi-async/ log4j-osgi/core-osgi-jpa/ log4j-osgi/core-osgi-legacy-... To: comm...@logging.apache.org Author: nickwilliams Date: Sat Feb 8 03:29:47 2014 New Revision: 1565902 URL: http://svn.apache.org/r1565902 Log: Corrected version number to follow Maven version number syntax; without this change, it might not be ordered correctly in Maven version ordering once published. Modified: logging/log4j/log4j2/trunk/log4j-1.2-api/pom.xml logging/log4j/log4j2/trunk/log4j-api/pom.xml logging/log4j/log4j2/trunk/log4j-core/pom.xml logging/log4j/log4j2/trunk/log4j-distribution/pom.xml logging/log4j/log4j2/trunk/log4j-flume-ng/pom.xml logging/log4j/log4j2/trunk/log4j-jcl/pom.xml logging/log4j/log4j2/trunk/log4j-jmx-gui/pom.xml logging/log4j/log4j2/trunk/log4j-osgi/core-osgi-async/pom.xml logging/log4j/log4j2/trunk/log4j-osgi/core-osgi-jpa/pom.xml logging/log4j/log4j2/trunk/log4j-osgi/core-osgi-legacy-api/pom.xml logging/log4j/log4j2/trunk/log4j-osgi/core-osgi-net/pom.xml logging/log4j/log4j2/trunk/log4j-osgi/core-osgi-nosql-couch/pom.xml logging/log4j/log4j2/trunk/log4j-osgi/core-osgi-nosql-mongo/pom.xml logging/log4j/log4j2/trunk/log4j-osgi/core-osgi-reduced/pom.xml logging/log4j/log4j2/trunk/log4j-osgi/pom.xml logging/log4j/log4j2/trunk/log4j-samples/flume-common/pom.xml logging/log4j/log4j2/trunk/log4j-samples/flume-embedded/pom.xml logging/log4j/log4j2/trunk/log4j-samples/flume-remote/pom.xml logging/log4j/log4j2/trunk/log4j-samples/pom.xml logging/log4j/log4j2/trunk/log4j-slf4j-impl/pom.xml logging/log4j/log4j2/trunk/log4j-taglib/pom.xml logging/log4j/log4j2/trunk/log4j-to-slf4j/pom.xml logging/log4j/log4j2/trunk/pom.xml Modified: logging/log4j/log4j2/trunk/log4j-1.2-api/pom.xml URL: http://svn.apache.org/viewvc/logging/log4j/log4j2/trunk/log4j-1.2-api/pom.xml?rev=1565902r1=1565901r2=1565902view=diff == --- logging/log4j/log4j2/trunk/log4j-1.2-api/pom.xml (original) +++ logging/log4j/log4j2/trunk/log4j-1.2-api/pom.xml Sat Feb 8 03:29:47 2014 @@ -20,7 +20,7 @@ parent groupIdorg.apache.logging.log4j/groupId artifactIdlog4j/artifactId -version2.0RC1-SNAPSHOT/version +version2.0-rc1-SNAPSHOT/version relativePath..//relativePath /parent artifactIdlog4j-1.2-api/artifactId Modified: logging/log4j/log4j2/trunk/log4j-api/pom.xml URL: http://svn.apache.org/viewvc/logging/log4j/log4j2/trunk/log4j-api/pom.xml?rev=1565902r1=1565901r2=1565902view=diff == --- logging/log4j/log4j2/trunk/log4j-api/pom.xml (original) +++ logging/log4j/log4j2/trunk/log4j-api/pom.xml Sat Feb 8 03:29:47 2014 @@ -20,7 +20,7 @@ parent groupIdorg.apache.logging.log4j/groupId artifactIdlog4j/artifactId -version2.0RC1-SNAPSHOT/version +version2.0-rc1-SNAPSHOT/version relativePath..//relativePath /parent artifactIdlog4j-api/artifactId Modified: logging/log4j/log4j2/trunk/log4j-core/pom.xml URL: http://svn.apache.org/viewvc/logging/log4j/log4j2/trunk/log4j-core/pom.xml?rev=1565902r1=1565901r2=1565902view=diff == --- logging/log4j/log4j2/trunk/log4j-core/pom.xml (original) +++ logging/log4j/log4j2/trunk/log4j-core/pom.xml Sat Feb 8 03:29:47 2014 @@ -20,7 +20,7 @@ parent groupIdorg.apache.logging.log4j/groupId artifactIdlog4j/artifactId -version2.0RC1-SNAPSHOT/version +version2.0-rc1-SNAPSHOT/version relativePath..//relativePath /parent artifactIdlog4j-core/artifactId Modified: logging/log4j/log4j2/trunk/log4j-distribution/pom.xml URL: http://svn.apache.org/viewvc/logging/log4j/log4j2/trunk/log4j-distribution/pom.xml?rev=1565902r1=1565901r2=1565902view=diff == --- logging/log4j/log4j2/trunk/log4j-distribution/pom.xml (original) +++ logging/log4j/log4j2/trunk/log4j-distribution/pom.xml Sat Feb 8 03:29:47 2014 @@ -20,7 +20,7 @@ parent groupIdorg.apache.logging.log4j/groupId artifactIdlog4j/artifactId -version2.0RC1-SNAPSHOT/version +version2.0-rc1-SNAPSHOT/version relativePath..//relativePath /parent artifactIdlog4j-distribution/artifactId Modified: logging/log4j/log4j2/trunk/log4j-flume-ng/pom.xml URL: http://svn.apache.org/viewvc/logging/log4j/log4j2/trunk/log4j-flume-ng/pom.xml?rev=1565902r1=1565901r2=1565902view=diff
