Re: [OGNL] Make use of logging?
On 11/11/2013 06:54 AM, Gary Gregory wrote: It sounds like the Commons Logging page should include text that refers to Log4j 2. I can imagine adding something like the following to the logging page: Active development of Commons Logging has stopped, only maintenance release for critical bugs are to be expected. Users are encouraged to migrate to other, more widely used logging frameworks which are under active development: * Log4J2 * SLF4J * ... We could also provide a migration guide for these users, which should be pretty straight-forward (at least for slf4j I know it). Thomas Gary Original message From: Christian Grobmeier grobme...@gmail.com Date:11/10/2013 15:46 (GMT-05:00) To: Commons Developers List dev@commons.apache.org Subject: Re: [OGNL] Make use of logging? On 10 Nov 2013, at 21:24, henrib wrote: Would you share why ? I'm sure it would be beneficial to others (including the commons logging community). Sorry I was short in my reply because I mentioned this a few times already. Didn't find the mails, so here we go: As you probably know, I have an interest in logging in general. Commons Logging doesn't support modern logging features. If you compare it to the Log4j2 API or to slf4j its just outdated. That said, people are already having a lot of problems with their logging dependencies. It's definitely not nice to have commons-logging in path, just because OGNL uses it. From all the log4j talks I gave recently there were zero people using commons-logging. For me it is dead. And I certainly don't recommend anybody to use it. Ok, lets say you have an interest in fixing Commons-Logging and implement modern API features. Why wouldn't you spend the time in Log4j2s API? It serves the same purpose, just with a better API. It's already there. Log4j2 users can use different logging implementations under the hood, if they like. Now why should there be another logging facade which needs a *lot* of work? Before the small maintenance release this year there was a 5 yrs break. Logging went on. Commons Logging did not. It's too late. Even if Commons would put a lot of effort I doubt anybody would accept it. Now we probably need some logging at OGNL. Do I want that outdated, irregulary maintained Commons Logging which seems to be used only at Tomcat? No absolutely not. Instead I am thinking commons logging implementation should stop. We will not win the fight against slf4j anymore. The only way out is unbelievable big marketing effort for the log4j2 api OR a new logging jsr. E-mail went longer than thought, sorry. Hope you understand a bit better why I can't support commons-logging going into OGNL. If any more questions please shout. Cheers Christian -- View this message in context: http://apache-commons.680414.n4.nabble.com/OGNL-Make-use-of-logging-tp4653577p4656667.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - 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
Re: Fwd: svn commit: r1540502 - /commons/proper/math/trunk/src/main/java/org/apache/commons/math3/stat/regression/AbstractMultipleLinearRegression.java
On 11/11/2013 01:07 AM, Phil Steitz wrote:
Clirr does not complain about this change, I guess because pre- and
post- are both unchecked, unadvertised exceptions. Before making
more of these changes, I want to make sure others are OK with this
in a dot release. Users who catch MathIllegalArgumentException will
not be affected by this change, but those who catch
NumberIsTooSmallException may break. I thought about having the new
exception subclass NumberIsTooSmallException, but that does not
really make sense to me. If others are not OK with this, I can roll
back this change and wait to start using the new exception in older
classes until 4.0.
If unsure, we could make it subclass NumberIsTooSmallException for now
and then change it to MathIllegalArgumentException in 4.0?
Thomas
Original Message
Subject: svn commit: r1540502 -
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/stat/regression/AbstractMultipleLinearRegression.java
Date: Sun, 10 Nov 2013 18:03:41 -
From: pste...@apache.org
Reply-To: dev@commons.apache.org
To: comm...@commons.apache.org
Author: psteitz
Date: Sun Nov 10 18:03:41 2013
New Revision: 1540502
URL: http://svn.apache.org/r1540502
Log:
Changed to use InsufficientDataException when the model does not contain
sufficient data for the number of regerssors; fixed error in precondition
statement.
Modified:
commons/proper/math/trunk/src/main/java/org/apache/commons/math3/stat/regression/AbstractMultipleLinearRegression.java
Modified:
commons/proper/math/trunk/src/main/java/org/apache/commons/math3/stat/regression/AbstractMultipleLinearRegression.java
URL:
http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/stat/regression/AbstractMultipleLinearRegression.java?rev=1540502r1=1540501r2=1540502view=diff
==
---
commons/proper/math/trunk/src/main/java/org/apache/commons/math3/stat/regression/AbstractMultipleLinearRegression.java
(original)
+++
commons/proper/math/trunk/src/main/java/org/apache/commons/math3/stat/regression/AbstractMultipleLinearRegression.java
Sun Nov 10 18:03:41 2013
@@ -17,10 +17,10 @@
package org.apache.commons.math3.stat.regression;
import org.apache.commons.math3.exception.DimensionMismatchException;
+import org.apache.commons.math3.exception.InsufficientDataException;
import org.apache.commons.math3.exception.MathIllegalArgumentException;
import org.apache.commons.math3.exception.NoDataException;
import org.apache.commons.math3.exception.NullArgumentException;
-import org.apache.commons.math3.exception.NumberIsTooSmallException;
import org.apache.commons.math3.exception.util.LocalizedFormats;
import org.apache.commons.math3.linear.NonSquareMatrixException;
import org.apache.commons.math3.linear.RealMatrix;
@@ -109,8 +109,8 @@ public abstract class AbstractMultipleLi
* @throws NullArgumentException if the data array is null
* @throws DimensionMismatchException if the length of the data array is
not equal
* to codenobs * (nvars + 1)/code
- * @throws NumberIsTooSmallException if codenobs/code is smaller than
- * codenvars/code
+ * @throws InsufficientDataException if codenobs/code is less than
+ * codenvars + 1/code
*/
public void newSampleData(double[] data, int nobs, int nvars) {
if (data == null) {
@@ -120,7 +120,7 @@ public abstract class AbstractMultipleLi
throw new DimensionMismatchException(data.length, nobs * (nvars
+ 1));
}
if (nobs = nvars) {
-throw new NumberIsTooSmallException(nobs, nvars, false);
+throw new
InsufficientDataException(LocalizedFormats.INSUFFICIENT_OBSERVED_POINTS_IN_SAMPLE,
nobs, nvars + 1);
}
double[] y = new double[nobs];
final int cols = noIntercept ? nvars: nvars + 1;
-
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
Re: Fwd: svn commit: r1540502 - /commons/proper/math/trunk/src/main/java/org/apache/commons/math3/stat/regression/AbstractMultipleLinearRegression.java
Le 11/11/2013 09:47, Thomas Neidhart a écrit :
On 11/11/2013 01:07 AM, Phil Steitz wrote:
Clirr does not complain about this change, I guess because pre- and
post- are both unchecked, unadvertised exceptions. Before making
more of these changes, I want to make sure others are OK with this
in a dot release.
As far as I am concerned, I am OK with this.
Users who catch MathIllegalArgumentException will
not be affected by this change, but those who catch
NumberIsTooSmallException may break. I thought about having the new
exception subclass NumberIsTooSmallException, but that does not
really make sense to me. If others are not OK with this, I can roll
back this change and wait to start using the new exception in older
classes until 4.0.
If unsure, we could make it subclass NumberIsTooSmallException for now
and then change it to MathIllegalArgumentException in 4.0?
I'm not sure it is worth the effort, and we may well forget about it
after 3.3.
Luc
Thomas
Original Message
Subject: svn commit: r1540502 -
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/stat/regression/AbstractMultipleLinearRegression.java
Date:Sun, 10 Nov 2013 18:03:41 -
From:pste...@apache.org
Reply-To:dev@commons.apache.org
To: comm...@commons.apache.org
Author: psteitz
Date: Sun Nov 10 18:03:41 2013
New Revision: 1540502
URL: http://svn.apache.org/r1540502
Log:
Changed to use InsufficientDataException when the model does not contain
sufficient data for the number of regerssors; fixed error in precondition
statement.
Modified:
commons/proper/math/trunk/src/main/java/org/apache/commons/math3/stat/regression/AbstractMultipleLinearRegression.java
Modified:
commons/proper/math/trunk/src/main/java/org/apache/commons/math3/stat/regression/AbstractMultipleLinearRegression.java
URL:
http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/stat/regression/AbstractMultipleLinearRegression.java?rev=1540502r1=1540501r2=1540502view=diff
==
---
commons/proper/math/trunk/src/main/java/org/apache/commons/math3/stat/regression/AbstractMultipleLinearRegression.java
(original)
+++
commons/proper/math/trunk/src/main/java/org/apache/commons/math3/stat/regression/AbstractMultipleLinearRegression.java
Sun Nov 10 18:03:41 2013
@@ -17,10 +17,10 @@
package org.apache.commons.math3.stat.regression;
import org.apache.commons.math3.exception.DimensionMismatchException;
+import org.apache.commons.math3.exception.InsufficientDataException;
import org.apache.commons.math3.exception.MathIllegalArgumentException;
import org.apache.commons.math3.exception.NoDataException;
import org.apache.commons.math3.exception.NullArgumentException;
-import org.apache.commons.math3.exception.NumberIsTooSmallException;
import org.apache.commons.math3.exception.util.LocalizedFormats;
import org.apache.commons.math3.linear.NonSquareMatrixException;
import org.apache.commons.math3.linear.RealMatrix;
@@ -109,8 +109,8 @@ public abstract class AbstractMultipleLi
* @throws NullArgumentException if the data array is null
* @throws DimensionMismatchException if the length of the data array
is not equal
* to codenobs * (nvars + 1)/code
- * @throws NumberIsTooSmallException if codenobs/code is smaller
than
- * codenvars/code
+ * @throws InsufficientDataException if codenobs/code is less than
+ * codenvars + 1/code
*/
public void newSampleData(double[] data, int nobs, int nvars) {
if (data == null) {
@@ -120,7 +120,7 @@ public abstract class AbstractMultipleLi
throw new DimensionMismatchException(data.length, nobs * (nvars
+ 1));
}
if (nobs = nvars) {
-throw new NumberIsTooSmallException(nobs, nvars, false);
+throw new
InsufficientDataException(LocalizedFormats.INSUFFICIENT_OBSERVED_POINTS_IN_SAMPLE,
nobs, nvars + 1);
}
double[] y = new double[nobs];
final int cols = noIntercept ? nvars: nvars + 1;
-
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
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[ANNOUNCE] Apache Commons Pool 2.0 released
The Apache Commons Team is pleased to announce the release of Apache Commons Pool 2.0. The Apache Commons Pool open source software library provides an object-pooling API and a number of object pool implementations. Version 2 of Apache Commons Pool contains a completely re-written pooling implementation compared to the 1.x series. In addition to significant performance and scalability improvements - particularly under highly concurrent loads, version 2 includes robust instance tracking and pool monitoring. Version 2 requires JDK level 1.6 or above. Source and binary distributions are available for download from the Apache Commons download site: http://commons.apache.org/proper/commons-pool/download_pool.cgi When downloading, please verify signatures using the KEYS file available at the above location when downloading the release. Version 2.0 is not backwards compatible with earlier releases. There have been numerous API changes to support new features as well as to clarify behaviour and improve consistency across the API. Therefore, to support side-by-side usage of 2.x and earlier versions, the packaging of version 2.0 has been changed to org.apache.commons.pool2. Full details of all the changes in 2.0 can be found in the changelog: http://commons.apache.org/proper/commons-pool/changes-report.html For complete information on Commons Pool, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Commons Pool website: http://commons.apache.org/proper/commons-pool/ 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
RE: [ANNOUNCE] Apache Commons Pool 2.0 released
Congrats to [pool] on a 2.0 finally seeing the light of day! Gary Original message From: Mark Thomas ma...@apache.org Date:11/11/2013 10:25 (GMT-05:00) To: Commons Users List u...@commons.apache.org Cc: Commons Developers List dev@commons.apache.org,annou...@apache.org Subject: [ANNOUNCE] Apache Commons Pool 2.0 released The Apache Commons Team is pleased to announce the release of Apache Commons Pool 2.0. The Apache Commons Pool open source software library provides an object-pooling API and a number of object pool implementations. Version 2 of Apache Commons Pool contains a completely re-written pooling implementation compared to the 1.x series. In addition to significant performance and scalability improvements - particularly under highly concurrent loads, version 2 includes robust instance tracking and pool monitoring. Version 2 requires JDK level 1.6 or above. Source and binary distributions are available for download from the Apache Commons download site: http://commons.apache.org/proper/commons-pool/download_pool.cgi When downloading, please verify signatures using the KEYS file available at the above location when downloading the release. Version 2.0 is not backwards compatible with earlier releases. There have been numerous API changes to support new features as well as to clarify behaviour and improve consistency across the API. Therefore, to support side-by-side usage of 2.x and earlier versions, the packaging of version 2.0 has been changed to org.apache.commons.pool2. Full details of all the changes in 2.0 can be found in the changelog: http://commons.apache.org/proper/commons-pool/changes-report.html For complete information on Commons Pool, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Commons Pool website: http://commons.apache.org/proper/commons-pool/ 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
Re: Snapshot vs. release sites.
On 11/06/2013 04:53 PM, Gary Gregory wrote: Hi All: I find it unhelpful and confusing at times to see Commons sites for -SNAPSHOT version. I'd prefer to be able to browse a whole site for any released version. This is especially handy when I want to find information for some older version I must work with through an inherited dependency. If I want to see reports on code coverage for older versions, for example, I have to download and build. Old sites are also handy when they provide browsable code and test code, useful when you are on your phone/tablet. The confusion is worse when an a major release is upcoming and the snapshot site is up instead of the previous maintenance release. There is usually no way to tell what information is valid for previous releases instead of the current release. If I am lucky the site has a Javadoc link to the released version. Some sites helpfully provide links to more than one Javadoc releases. Just like we sometimes have links to previous Javadocs, I'd like to see somewhere in the menu, a choice of versions to take me to older released version of Commons sites. Thoughts? I like having snapshot versions as published site for the following reasons: * able to update / correct the site during releases - faster * giving users quick feedback what is going on in trunk (changelog / javadoc) Prior to 1.1.2, commons-logging had also old released versions published on the site, but it was quite a mess, as the links were mostly broken and the navigation gets completely messed up once you browse to an old release. I think with our current site publishing tools this can only be done if we do something similar as with the old javadocs versions, but I question if it makes sense to look at old sites, the should be outdated anyway. Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [beanutils] Preparing next release
Hi Benedikt, Am 10.11.2013 22:36, schrieb Benedikt Ritter: Hello, I'm back from a conference week and I hope to find the time to have a look at trunk this week. I also want to go through jira and do some work on the tickets. From my perspective this will be the last minor release. So every feature request should either be resolved or targeted to 2.0 (if it makes sense). Doing a binary compartible release with generics is a good idea (and thank you Oliver for doing all the work!), but we should start working on BU2 again, after this release. Every help is appreciated! However, I would not spend too much time with working on Jira Tickets. I prefer getting the release out pretty soon. The time is better spent working on BU2. Oliver Benedikt Send from my mobile device Am 10.11.2013 um 19:41 schrieb Oliver Heger oliver.he...@oliver-heger.de: Hi Paul, many thanks for your feedback. Am 10.11.2013 04:28, schrieb Paul Benedict: Some feedback: 1) Classes with HTML formatting problems that are messing up the javadocs. They are likely all due to missing end tags: * MappedPropertyDescriptor * LazyDynaMap * LazyDyanClass * LazyDynaBean * ConvertUtilsBean * BeanPropertyValueEqualsPredicate * BasicDynaBean Fixed. Thanks for spotting this. 2) Does Converter have a contract to convert multiple type Ts or just one type T? Type T is in the method signature only but if the implementation is only supposed to convert one type, it should become a class type. Indeed, converters can support multiple types. A typical converter implements a conversion to a specific target type and a conversion to string. (To be honest, I do not like this design very much, but now it is too late to change.) 3) I am not a fan of B in BeanComparator. It makes me think too hard. I prefer T. Okay, changed in SVN. I wanted to be too clever ;-) Paul On Sat, Nov 9, 2013 at 2:16 PM, Oliver Heger oliver.he...@oliver-heger.dewrote: Hi Paul, Am 09.11.2013 19:31, schrieb Paul Benedict: Oliver, would you have time to publish a snapshot of 1.9's site so I can browse the javadocs and source xref? I can easily provide feedback if you do that. thanks for your interest! I uploaded the site to [1]. All comments are welcome! Oliver [1] http://people.apache.org/~oheger/beanutils-site/index.html On Sat, Nov 9, 2013 at 12:07 PM, Oliver Heger oliver.he...@oliver-heger.dewrote: Just a heads-up that I intend to start the preparations for a [beanutils] 1.9.0 release soon. So if there is something you want to see included in this release, now is a good time to step up. It would be great if somebody could find the time to review the changes made for adding generics [1]. TIA Oliver [1] https://issues.apache.org/jira/browse/BEANUTILS-452 - 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 - 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[VOTE] Release of Commons Collections 4.0 based on RC3
Hi, I'd like to call a vote for releasing Commons Collections 4.0 based on RC3. Changes since RC2: * [COLLECTIONS-499] Refactored the test framework for Bag implementations to extend from AbstractCollectionTest by decorating the concrete Bag instance with a CollectionBag or CollectionSortedBag. * [COLLECTIONS-498] CollectionBag will now also respect the contract of the decorated bag in case a null argument is provided to either removeAll or retainAll. * [COLLECTIONS-497] Added bag decorator CollectionSortedBag which decorates a SortedBag to make it comply with the Collection contract. * [COLLECTIONS-496] UnmodifiableBoundedCollection does now also implement the marker interface Unmodifiable similar as all other unmodifiable decorators. * [COLLECTIONS-495] UnmodifiableTrie#unmodifiableTrie(Trie) will not decorate again an already unmodifiable Trie. Also the return type has been changed to Trie to be consistent with other Unmodifiable decorators. * [COLLECTIONS-494] Moved Equator interface to base package for consistency. Thanks to Emmanuel Bourg. * improved release notes with suggestions from Emmanuel Bourg * added unit tests for TrieUtils and QueueUtils and factory methods for all Unmodifiable decorators * added more unit tests for the Queue interface * cleanup of many test classes: removed unused imports, unneeded constructors Changes since RC1: * release notes are now also included in the binary distribution * removed spurious hashCode() method in AbstractPatriciaTrie, the inherited one from AbstractMap will be used instead Collections 4.0 RC3 is available for review here: https://dist.apache.org/repos/dist/dev/commons/collections/ (svn revision 3477) Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-118/org/apache/commons/commons-collections4/4.0/ The tag is here: https://svn.apache.org/repos/asf/commons/proper/collections/tags/COLLECTIONS_4_0_RC3/ (svn revision 1540843) Site: http://people.apache.org/builds/commons/collections/4.0/RC3/ Details of changes can be found in the release notes: https://dist.apache.org/repos/dist/dev/commons/collections/RELEASE-NOTES.txt http://people.apache.org/builds/commons/collections/4.0/RC3/changes-report.html Please review the release candidate and vote. This vote will close no sooner than 72 hours from now. [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Note: the clirr report is generated against 4.0-alpha1 and it is also highlighted in the release notes that this release is not compatible with any previous release. Note2: there have been reports in the past that some unit tests fail with certain versions of the IBM Java 6 VM. Some tests have been disabled when run with a IBM Java 6 VM due to some bugs in the java.util.TreeMap implementation, but it may still fail for other versions. Thank you for your reviews, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Snapshot vs. release sites.
On Fri, Nov 8, 2013 at 4:24 AM, sebb seb...@gmail.com wrote: On 7 November 2013 17:45, Phil Steitz phil.ste...@gmail.com wrote: On 11/6/13 10:11 PM, Henri Yandell wrote: On Wed, Nov 6, 2013 at 7:53 AM, Gary Gregory garydgreg...@gmail.com wrote: Hi All: I find it unhelpful and confusing at times to see Commons sites for -SNAPSHOT version. I'd prefer to be able to browse a whole site for any released version. This is especially handy when I want to find information for some older version I must work with through an inherited dependency. The tail is wagging the dog (ie: Maven is leading us astray). This is nothing to do with Maven per se. It's just a question of what source is used to build the website. There's the tail wagging us. Why is source (of the component) used to build the website? The notion of a website having a version is absurd :) [other than its own svn/git versioning] +1 - I tend to agree with the site == head approach that we have pretty much always taken. I like the Tomcat approach of making versioned site content available for past releases, but that is a pain to maintain and I am loathe to ask more from Commons RMs atm or to clutter svn with ever more little maven-generated files. For most Commons components, there is not much beyond the javadoc anyway, which in most cases is already published for old releases. Forget about Commons for a moment. Consider Maven Plugin websites. Would they be useful if they only showed the documentation for the unreleased head version of the plugin? No, of course not; it's essential the the user can readily find documentation for the current release. It would be nice if docs were also available for selected earlier releases as well, but that is a separate issue. If we assume that users cannot manage documentation on their own, which I think is fair, then it's essential the user can readily find the documentation for the release they are using. I think every component's site should be akin to (assume lots of cross-referenced linking): index.html - Boilerplate blurb. Latest release info. releases.html - Info about every release. docs/** - Docs for each release. ie) Javadoc + User Guide; though if we wanted to also bundle quality docs we could (but I think it's pointless). download/** - Download each release [obviously would be mirror structure etc] None of those have anything to do with versions of source. Hen
Re: [LANG] Release 3.2?
It's wrong imo :) Useless parentheses - I didn't author them, but just looking at the code I find them useful. I think PMD's passed the point of value for us. Too much noise over stylistic items (ie: checkstyle's domain without checkstyle's configuration) and not enough being flagged for real problems (where it always used to excel at being a more specific equivalent to FindBugs). Hen On Sun, Nov 10, 2013 at 1:41 PM, Benedikt Ritter benerit...@gmail.comwrote: What about the PMD Report? It is mostly about parantheses. I don't See a problem here, but better ask first, before we do the first RC. Benedikt Send from my mobile device Am 07.11.2013 um 07:15 schrieb Gary Gregory garydgreg...@gmail.com: Release early, release often :) Original message From: Henri Yandell flame...@gmail.com Date:11/07/2013 01:13 (GMT-05:00) To: Commons Developers List dev@commons.apache.org Subject: [LANG] Release 3.2? I'm thinking we should be rolling a 3.2 release. Any opinions? Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Applying GitHub pull requests
Apologies if this is obvious to all, but I figured I'd share as it took a moment to look it up and get the right answer out of the noise on StackOverflow :) A simple way to apply a GitHub pull request, say: https://github.com/apache/commons-lang/pull/11/ Download (wget etc) https://github.com/apache/commons-lang/pull/11.patchand use: patch -p1 11.patch [huge assumption that people have patch on the command line] Hen
Re: Applying GitHub pull requests
On Tue, Nov 12, 2013 at 12:43 AM, Henri Yandell flame...@gmail.com wrote: Apologies if this is obvious to all, but I figured I'd share as it took a moment to look it up and get the right answer out of the noise on StackOverflow :) A simple way to apply a GitHub pull request, say: https://github.com/apache/commons-lang/pull/11/ Download (wget etc) https://github.com/apache/commons-lang/pull/11.patchand use: patch -p1 11.patch [huge assumption that people have patch on the command line] There is also svn patch ... Gary Hen -- 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
