[GitHub] commons-collections pull request #58: Fix Rat check - add missing license he...
Github user asfgit closed the pull request at: https://github.com/apache/commons-collections/pull/58 --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] java8 default interface methods for lazy log payload object creation
On Tue, 13 Nov 2018 at 15:21, Gary Gregory wrote: > On Tue, Nov 13, 2018 at 2:03 PM Matt Sicker wrote: > > > I thought Commons Logging 1.2 required Java 1.2? Big leap to 8! > > > > The current POM requires Java 6. > I must have confused that with the prior release then which is Java 1.1 I think. -- Matt Sicker
Re: [logging] java8 default interface methods for lazy log payload object creation
On Tue, Nov 13, 2018 at 2:03 PM Matt Sicker wrote:
> I thought Commons Logging 1.2 required Java 1.2? Big leap to 8!
>
The current POM requires Java 6.
Gary
>
> Same bias here for Log4j2, though adding simple default methods like that
> would be neat for any APIs stuck using it (like Spring Framework for
> example).
>
> On Tue, 13 Nov 2018 at 14:52, Gary Gregory wrote:
>
> > Hi Balazs,
> >
> > To me, as a biased contributor to Apache Log4j 2, I think the Log4j API
> > should be new facade to use instead of Commons Logging.
> >
> > That said, please feel free to contribute PRs to Commons Logging for
> those
> > using that API ;-)
> >
> > https://github.com/apache/commons-logging
> >
> > Gary
> >
> > On Tue, Nov 13, 2018 at 1:24 PM Balazs Toth wrote:
> >
> > > Hi,
> > >
> > > I am wondering to extend the org.apache.commons.logging.Log interface
> > with
> > > default methods.
> > >
> > > It could simplify the usage, instead of
> > >
> > > if (log.isDebugEnabled()) {
> > > log.debug("something heavy " + here);
> > > }
> > >
> > > could use lambda expression
> > > log.debug(() -> "something heavy " + here);
> > >
> > > to prevent the payload creation if the certain log level not enabled.
> > >
> > > so the org.apache.commons.logging.Log interface would get the following
> > > default methods:
> > >
> > > default void debug(Supplier msgSupplier) {
> > > if (isDebugEnabled()) {
> > > debug(msgSupplier != null ? msgSupplier.get() :
> > > null);
> > > }
> > > }
> > >
> > > default void debug(Supplier msgSupplier, Throwable t) {
> > > if (isDebugEnabled()) {
> > > debug(msgSupplier != null ? msgSupplier.get() :
> > > null, t);
> > > }
> > > }
> > >
> > > of course not just for debug, I would create for all the log levels.
> > >
> > > Obviously that should need a new version like 1.3.0 because the Java
> > > source and target level must raise to 1.8 from the current 1.6.
> > >
> > > What do you think, is the community would accept this change?
> > >
> > > Regards, Balazs
> >
>
>
> --
> Matt Sicker
>
Re: [logging] java8 default interface methods for lazy log payload object creation
I thought Commons Logging 1.2 required Java 1.2? Big leap to 8!
Same bias here for Log4j2, though adding simple default methods like that
would be neat for any APIs stuck using it (like Spring Framework for
example).
On Tue, 13 Nov 2018 at 14:52, Gary Gregory wrote:
> Hi Balazs,
>
> To me, as a biased contributor to Apache Log4j 2, I think the Log4j API
> should be new facade to use instead of Commons Logging.
>
> That said, please feel free to contribute PRs to Commons Logging for those
> using that API ;-)
>
> https://github.com/apache/commons-logging
>
> Gary
>
> On Tue, Nov 13, 2018 at 1:24 PM Balazs Toth wrote:
>
> > Hi,
> >
> > I am wondering to extend the org.apache.commons.logging.Log interface
> with
> > default methods.
> >
> > It could simplify the usage, instead of
> >
> > if (log.isDebugEnabled()) {
> > log.debug("something heavy " + here);
> > }
> >
> > could use lambda expression
> > log.debug(() -> "something heavy " + here);
> >
> > to prevent the payload creation if the certain log level not enabled.
> >
> > so the org.apache.commons.logging.Log interface would get the following
> > default methods:
> >
> > default void debug(Supplier msgSupplier) {
> > if (isDebugEnabled()) {
> > debug(msgSupplier != null ? msgSupplier.get() :
> > null);
> > }
> > }
> >
> > default void debug(Supplier msgSupplier, Throwable t) {
> > if (isDebugEnabled()) {
> > debug(msgSupplier != null ? msgSupplier.get() :
> > null, t);
> > }
> > }
> >
> > of course not just for debug, I would create for all the log levels.
> >
> > Obviously that should need a new version like 1.3.0 because the Java
> > source and target level must raise to 1.8 from the current 1.6.
> >
> > What do you think, is the community would accept this change?
> >
> > Regards, Balazs
>
--
Matt Sicker
Re: [logging] java8 default interface methods for lazy log payload object creation
Hi Balazs,
To me, as a biased contributor to Apache Log4j 2, I think the Log4j API
should be new facade to use instead of Commons Logging.
That said, please feel free to contribute PRs to Commons Logging for those
using that API ;-)
https://github.com/apache/commons-logging
Gary
On Tue, Nov 13, 2018 at 1:24 PM Balazs Toth wrote:
> Hi,
>
> I am wondering to extend the org.apache.commons.logging.Log interface with
> default methods.
>
> It could simplify the usage, instead of
>
> if (log.isDebugEnabled()) {
> log.debug("something heavy " + here);
> }
>
> could use lambda expression
> log.debug(() -> "something heavy " + here);
>
> to prevent the payload creation if the certain log level not enabled.
>
> so the org.apache.commons.logging.Log interface would get the following
> default methods:
>
> default void debug(Supplier msgSupplier) {
> if (isDebugEnabled()) {
> debug(msgSupplier != null ? msgSupplier.get() :
> null);
> }
> }
>
> default void debug(Supplier msgSupplier, Throwable t) {
> if (isDebugEnabled()) {
> debug(msgSupplier != null ? msgSupplier.get() :
> null, t);
> }
> }
>
> of course not just for debug, I would create for all the log levels.
>
> Obviously that should need a new version like 1.3.0 because the Java
> source and target level must raise to 1.8 from the current 1.6.
>
> What do you think, is the community would accept this change?
>
> Regards, Balazs
[logging] java8 default interface methods for lazy log payload object creation
Hi,
I am wondering to extend the org.apache.commons.logging.Log interface with
default methods.
It could simplify the usage, instead of
if (log.isDebugEnabled()) {
log.debug("something heavy " + here);
}
could use lambda expression
log.debug(() -> "something heavy " + here);
to prevent the payload creation if the certain log level not enabled.
so the org.apache.commons.logging.Log interface would get the following default
methods:
default void debug(Supplier msgSupplier) {
if (isDebugEnabled()) {
debug(msgSupplier != null ? msgSupplier.get() : null);
}
}
default void debug(Supplier msgSupplier, Throwable t) {
if (isDebugEnabled()) {
debug(msgSupplier != null ? msgSupplier.get() : null,
t);
}
}
of course not just for debug, I would create for all the log levels.
Obviously that should need a new version like 1.3.0 because the Java source and
target level must raise to 1.8 from the current 1.6.
What do you think, is the community would accept this change?
Regards, Balazs
Re: Release Managers?
If anyone would like to take over commons-imaging 1.0-alpha1 release. We had up to RC2 I think, so there should be little left to do. I can volunteer around x-mas or January/19 I think. Bruno From: Gary Gregory To: Commons Developers List Sent: Wednesday, 14 November 2018 8:34 AM Subject: Release Managers? Hi All: It looks like we have a release manager volunteer for Commons Pool 2.6.1; thank you Mark! I'd also like to see releases for: - Commons Release - Commons Parent - Commons Text, then Commons Configuration after a teak in Config to use a new Text feature. - Commons Pool - Commons Collection, a request from OpenJPA Anything else imminent? We also have Commons BeanUtils that will be a major release but I am not sure if more API breakage/deprecation is needed. Gary
Release Managers?
Hi All: It looks like we have a release manager volunteer for Commons Pool 2.6.1; thank you Mark! I'd also like to see releases for: - Commons Release - Commons Parent - Commons Text, then Commons Configuration after a teak in Config to use a new Text feature. - Commons Pool - Commons Collection, a request from OpenJPA Anything else imminent? We also have Commons BeanUtils that will be a major release but I am not sure if more API breakage/deprecation is needed. Gary
[GitHub] commons-collections pull request #58: Fix Rat check - add missing license he...
GitHub user nandorKollar opened a pull request: https://github.com/apache/commons-collections/pull/58 Fix Rat check - add missing license header Fix broken CI - add missing license header for Rat check You can merge this pull request into a Git repository by running: $ git pull https://github.com/nandorKollar/commons-collections fix_rat Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-collections/pull/58.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #58 commit a2daf347c33977b41b8e5390ac96dcf009d8550d Author: Nandor Kollar Date: 2018-11-13T13:53:05Z Fix Rat check - add missing licence header --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE][CANCEL] Release Apache Commons Pool 2.6.1 based on RC1
yes, they are. I create a new test to showcase the problem and only then fix it. All other tests still pass. LieGrue, strub > Am 12.11.2018 um 16:05 schrieb Gary Gregory : > > Hi Mark, > > Too many bits flying around on my end here. Can you check that your changes > are covered by unit tests? That should do it I hope. > > Gary > > On Mon, Nov 12, 2018 at 12:56 AM Mark Struberg > wrote: > >> sorry should have read "did anyone TEST my pool fixes". >> >> LieGrue, >> strub >> >> >>> Am 10.11.2018 um 23:24 schrieb Gary Gregory : >>> >>> On Sat, Nov 10, 2018 at 1:24 PM Mark Struberg >> >>> wrote: >>> Did anyone fix my pool fixes? >>> >>> >>> Hi Mark, >>> >>> Can you be more specific or just check git master? >>> >>> The latest deployed pool and dbcp2 snapshots do contain them. >>> >>> So we are good then, right? >>> >>> Would love to start a release but I think I need some guidance. Any docs for how it runs in commons land? >>> >>> I think Rob updated the Wiki: >> https://commons.apache.org/releases/index.html >>> >>> Gary >>> >>> txs and LieGrue,strub On Friday, 2 November 2018, 17:01:44 CET, Gary Gregory < garydgreg...@gmail.com> wrote: I am cancelling this VOTE, long overdue, sorry. There are additional bug fixes that have come in as well... Gary On Thu, Aug 23, 2018 at 7:39 AM Gary Gregory wrote: > > > On Wed, Aug 22, 2018 at 1:14 PM Benedikt Ritter > wrote: > >> Hi Gary, >> Am Mi., 22. Aug. 2018 um 16:04 Uhr schrieb Gary Gregory < >> garydgreg...@gmail.com>: >> >>> WRT signing tags, ATM, I cannot git's -s option to work with GPG on >>> Windows. Any clues? >>> >> >> Sorry, I'm on macOS. For that to work I needed to have the gpg-agent >> running. But I don't know whether this is a unix thing. >> >> The tag signing alone would not cause me to vote -1. I can live with >> an >> unsigned tag. What really needs to be fixed are the differences >> between >> src >> distribution and release tag in my opinion. I'll have time on Saturday to >> have a look into that if you don't get to it until then. >> > > I welcome the help :-) Quite busy at work. > > Gary > >> >> Regards, >> Benedikt >> >> >>> >>> Gary >>> >>> On Tue, Aug 21, 2018 at 1:06 AM Benedikt Ritter >>> wrote: >>> Hello Gary, -1, I there are several issues that we need to fix this before we can release 2.6.1. I think the RELEASE NOTES need more work: "The Apache Commons Pool team is pleased to announce the release of >>> Apache Commons Pool 2.6.1-SNAPSHOT." "No client code changes are required to migrate from versions 2.0-2.3 >> to version 2.4.3." - what about migration to 2.6.1? "Version 2 requires JDK level 1.6 or above" - Website states that >> Java 7 >>> is required. The release tag is not signed: ~/w/a/r/p/commons-pool git:(master) > git tag -v >> commons-pool-2.6.1-RC1 object 87c5dc14a967a70dd6e640395d4e842b021cdb8f type commit tag commons-pool-2.6.1-RC1 tagger Gary Gregory 1534517006 -0600 Tag Apache Commons Pool release 2.6.1 RC1 error: no signature found There are various differences between to release tag in git and the contents of the src archive: ~/w/a/r/pool-2.6.1 > diff -rq commons-pool commons-pool2-2.6.1-src Only in commons-pool: .git Only in commons-pool: .gitignore Only in commons-pool: .travis.yml Only in commons-pool: CONTRIBUTING.md Files commons-pool/NOTICE.txt and commons-pool2-2.6.1-src/NOTICE.txt >>> differ Only in commons-pool: README.md Files commons-pool/RELEASE-NOTES.txt and commons-pool2-2.6.1-src/RELEASE-NOTES.txt differ Files commons-pool/pom.xml and commons-pool2-2.6.1-src/pom.xml differ Only in commons-pool: pool-RC.sh Only in commons-pool: pool-pre-RC.sh Only in commons-pool: pool-release.sh Only in commons-pool/src: assembly Files commons-pool/src/changes/changes.xml and commons-pool2-2.6.1-src/src/changes/changes.xml differ Files commons-pool/src/site/resources/download_pool.cgi and commons-pool2-2.6.1-src/src/site/resources/download_pool.cgi differ Files commons-pool/src/site/site.xml and commons-pool2-2.6.1-src/src/site/site.xml differ Files commons-pool/src/site/xdoc/index.xml and commons-pool2-2.6.1-src/src/site/xdoc/index.xml differ Files commons-pool/src/site/xdoc/issue-tracking.xml and
