Re: svn commit: r1807421 - /commons/proper/vfs/trunk/BUILDING.txt

[Bernd Eckenfels]

> -mvn clirr:check -pl core
> +mvn clirr:check -pl commons-vfs2

Hmm, I think it is intentionally only building the core module, if that is no 
longer required would it be better to completely remove the -pl argument to 
control partial build?

Gruss
Bernd
--
http://bernd.eckenfels.net

Re: [JCS] update to Log4j 2 facade API

[Romain Manni-Bucau]

@Ralph: for tomcat you can use their SPI (
https://github.com/apache/meecrowave/blob/trunk/meecrowave-core/src/main/java/org/apache/meecrowave/logging/tomcat/Log4j2Log.java).
For tomee it is harder since tomee itself has an API (LogStream) but OWB
and cxf uses JUL as API (as mentionned before) and several libs use
slf4j-api first etc...The move to JUL was really about consistency, if we
get it for log4j2 adding 3-4 integrations and prevent users to use log4j in
the app then we loose most of the work :(. For log4j2 in a container we
also need a hack to not loose logs at shutdown (ctrl+x):
https://github.com/apache/tomee/blob/master/utils/log4j2-tomee/src/main/java/org/apache/tomee/log4j2/Log4j2ShutdownHooksExecutor.java.
Seems JUL doesn't have this issue, not sure why (surely "internal" shutdown
hooks ordering).


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | JavaEE Factory


2017-09-05 21:06 GMT+02:00 Ralph Goers :

> Please point me at the doc for how TomEE would expect us to implement it.
> The doc for Tomcat is at https://tomcat.apache.org/
> tomcat-8.5-doc/logging.html  tomcat-8.5-doc/logging.html>, which indicates that implementing a Handler
> is the only option. If you have a better way please share.
>
> Ralph
>
> > On Sep 5, 2017, at 11:20 AM, Romain Manni-Bucau 
> wrote:
> >
> > @Ralph: not exactly, if you check tomee/meecowave/cxf, all have Logger
> > implementations backed by something else. Integration is more or less
> good
> > depending the requirements but extending logger you get an implementation
> > almost as fast as a native log4j. It keeps JUL as API which also allows a
> > dependency free solution. Only constraint is to create the jul Logger
> > through a framework factory if you don't want to depend on the LogManager
> > which is sadly set only on the JVM. The integration (Log4j2Logger) could
> be
> > owned by log4j2 (i assume it is in jul integration maybe?). It is better
> > than a handler since it bypasses jul completely when switching and goes
> on
> > the impl directly. Summary is "jul is bad" doesnt mean dont use jul since
> > you can make it good and stay dependency free for frameworks which is
> quite
> > important for not final dependencies (= you dont know if the app is used
> in
> > a final app or as a library in a stack).
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github  rmannibucau> |
> > LinkedIn  | JavaEE Factory
> > 
> >
> > 2017-09-05 20:13 GMT+02:00 Gary Gregory :
> >
> >> On Tue, Sep 5, 2017 at 11:03 AM, Ralph Goers <
> ralph.go...@dslextreme.com>
> >> wrote:
> >>
> >>>
>  On Sep 5, 2017, at 9:19 AM, Romain Manni-Bucau  >
> >>> wrote:
> 
>  Le 5 sept. 2017 17:35, "Ralph Goers"  >>> > a écrit :
> 
> 
> > On Sep 5, 2017, at 6:45 AM, Romain Manni-Bucau <
> rmannibu...@gmail.com
> >>>
>  wrote:
> >
> >>
> >
> > I think it must go the other way: log4j2 must push projects to move
> > otherwise projects will be happy with X -> log4j2 bridges, no?
> 
>  We already have support for bridging other APIs to Log4j 2.
> 
> 
>  Not bypassing jul impl without a logmanager right? That is what does
>  frameworks api
> >>>
> >>> Is what you are asking for the same as what is asked for in
> >>> https://issues.apache.org/jira/browse/LOG4J2-2025? <
> >>> https://issues.apache.org/jira/browse/LOG4J2-2025?> If so, I am
> planning
> >>> on doing that although that integration will not make users very happy.
> >>> This is one of the reasons that jul sucks.
> >>>
> >>
> >> Ralph,
> >>
> >> Do you want to assign that issue to yourself? That would allow others to
> >> focus on different tickets.
> >>
> >> Gary
> >>
> >>
> >>>
> >>> Ralph
> >>
>
>

Re: [LANG] Releasing 3.6.1

[Pascal Schumacher]

+1

Am 5. September 2017 07:17:57 MESZ schrieb Benedikt Ritter :
>Hi,
>
>since we’re getting more and more requests about the deprecation of
>RandomStringUtils, I’m thinking about releasing the current state of
>the master branch as 3.6.1. I may have time to push an RC sometime this
>week. So if you have some fixes you want to include, please do so now.
>
>Regards,
>Benedikt
>-
>To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>For additional commands, e-mail: dev-h...@commons.apache.org

Re: [CANCEL][VOTE] Release Commons Jelly 1.0.1 based on RC3.

[Gary Gregory]

On Tue, Sep 5, 2017 at 1:00 PM, Rob Tompkins  wrote:

> As I haven’t gotten any votes on this thread I’m going to cancel for
> another attempt at building instructions along with adding the docker
> infrastructure with the project.
>

Would it be simpler to provide instructions without Docker in play like
"Use Ant 1.x and run this and that Ant command?"

Gary


>
> Cheers,
> -Rob
>
> > On Sep 1, 2017, at 10:35 PM, Rob Tompkins  wrote:
> >
> > Hello,
> >
> > Commons Jelly 1.0.1 RC3 is available for review here:
> >  https://dist.apache.org/repos/dist/dev/commons/jelly (svn revision
> 21410)
> >
> > The tag is here:
> >  https://svn.apache.org/repos/asf/commons/proper/jelly/tags/
> commons-jelly-1.0.1-RC3
> >
> > Commit the tag points at:
> >  1807023
> >
> > Maven Artifacts:
> >  https://repository.apache.org/content/repositories/
> orgapachecommons-1261
> >
> > These are the Maven artifacts and their hashes:
> >
> > /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-javadoc.jar
> >  orgapachecommons-1261/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1-javadoc.jar>
> > (SHA1: 1ccd4030ed815d9b3f3b020c0b9e212f709b)
> > /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-sources.jar.asc
> >  orgapachecommons-1261/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1-sources.jar.asc>
> > (SHA1: 36657bc375f8dcade51d1dbd067a80126895b41e)
> > /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.pom.asc
> >  orgapachecommons-1261/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1.pom.asc>
> > (SHA1: b77f35770a0476d575b777130f5629693e292374)
> > /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.pom
> >  orgapachecommons-1261/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1.pom>
> > (SHA1: 65333d0abdce02b3ae3a54c513c19b7aa04749ba)
> > /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.jar.asc
> >  orgapachecommons-1261/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1.jar.asc>
> > (SHA1: 6f6b0cd5bf67fce3e176208fb89e8f5a9a7fd517)
> > /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-javadoc.jar.asc
> >  orgapachecommons-1261/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1-javadoc.jar.asc>
> > (SHA1: 73d76f9bf582799717c42eaa951885933231d62e)
> > /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-sources.jar
> >  orgapachecommons-1261/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1-sources.jar>
> > (SHA1: dbc0153a76f706f4cb44f5631633157adbeb6a4d)
> > /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.jar
> >  orgapachecommons-1261/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1.jar>
> > (SHA1: 8ef47080d6baf4910f4707e3ce5612d32cd17fc0)
> > /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-tests.jar.asc
> >  orgapachecommons-1261/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1-tests.jar.asc>
> > (SHA1: cb34a2dfac65164f1a214d99e0701064fd251172)
> > /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-
> test-sources.jar.asc
> >  orgapachecommons-1261/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1-test-sources.jar.asc>
> > (SHA1: 868f8155ad8cddcbe3f72367091b9787d7b002b6)
> > /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-test-sources.jar
> >  orgapachecommons-1261/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1-test-sources.jar>
> > (SHA1: e1f7a6949a3d452b32236f1eec91b1629fec847b)
> > /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-tests.jar
> >  orgapachecommons-1261/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1-tests.jar>
> > (SHA1: 58ed6f095e6159a202c75fe62f08137a14814e7c)
> >
> > I have tested this with JDK 1.5.0_22-b03 using Ant 1.6.0. Notes on
> building can be found in the
> > BUILDING.md included in the source distributions.
> >
> > Details of changes since 1.0 are in the release notes:
> >https://dist.apache.org/repos/dist/dev/commons/jelly/
> RELEASE-NOTES.txt
> >
> > Site:
> >  I have no site as this was generated with ant. My plan was to
> simply make minimal
> >  changes to the existent site for the purpose of documenting the
> patch.
> >
> > KEYS:
> >  https://www.apache.org/dist/commons/KEYS
> >
> > Please review the release candidate and vote.
> > This vote will close no sooner that 72 hours from now,
> > i.e. sometime after 02:40 (UTC) 5-September 2017
> >
> >  [ ] +1 Release these artifacts
> >  [ ] +0 OK,

Re: [JCS] update to Log4j 2 facade API

[Ralph Goers]

Please point me at the doc for how TomEE would expect us to implement it. The 
doc for Tomcat is at https://tomcat.apache.org/tomcat-8.5-doc/logging.html 
, which indicates that 
implementing a Handler is the only option. If you have a better way please 
share.

Ralph

> On Sep 5, 2017, at 11:20 AM, Romain Manni-Bucau  wrote:
> 
> @Ralph: not exactly, if you check tomee/meecowave/cxf, all have Logger
> implementations backed by something else. Integration is more or less good
> depending the requirements but extending logger you get an implementation
> almost as fast as a native log4j. It keeps JUL as API which also allows a
> dependency free solution. Only constraint is to create the jul Logger
> through a framework factory if you don't want to depend on the LogManager
> which is sadly set only on the JVM. The integration (Log4j2Logger) could be
> owned by log4j2 (i assume it is in jul integration maybe?). It is better
> than a handler since it bypasses jul completely when switching and goes on
> the impl directly. Summary is "jul is bad" doesnt mean dont use jul since
> you can make it good and stay dependency free for frameworks which is quite
> important for not final dependencies (= you dont know if the app is used in
> a final app or as a library in a stack).
> 
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | JavaEE Factory
> 
> 
> 2017-09-05 20:13 GMT+02:00 Gary Gregory :
> 
>> On Tue, Sep 5, 2017 at 11:03 AM, Ralph Goers 
>> wrote:
>> 
>>> 
 On Sep 5, 2017, at 9:19 AM, Romain Manni-Bucau 
>>> wrote:
 
 Le 5 sept. 2017 17:35, "Ralph Goers" >> > a écrit :
 
 
> On Sep 5, 2017, at 6:45 AM, Romain Manni-Bucau >> 
 wrote:
> 
>> 
> 
> I think it must go the other way: log4j2 must push projects to move
> otherwise projects will be happy with X -> log4j2 bridges, no?
 
 We already have support for bridging other APIs to Log4j 2.
 
 
 Not bypassing jul impl without a logmanager right? That is what does
 frameworks api
>>> 
>>> Is what you are asking for the same as what is asked for in
>>> https://issues.apache.org/jira/browse/LOG4J2-2025? <
>>> https://issues.apache.org/jira/browse/LOG4J2-2025?> If so, I am planning
>>> on doing that although that integration will not make users very happy.
>>> This is one of the reasons that jul sucks.
>>> 
>> 
>> Ralph,
>> 
>> Do you want to assign that issue to yourself? That would allow others to
>> focus on different tickets.
>> 
>> Gary
>> 
>> 
>>> 
>>> Ralph
>> 

[CANCEL][VOTE] Release Commons Jelly 1.0.1 based on RC3.

[Rob Tompkins]

As I haven’t gotten any votes on this thread I’m going to cancel for another 
attempt at building instructions along with adding the docker infrastructure 
with the project.

Cheers,
-Rob

> On Sep 1, 2017, at 10:35 PM, Rob Tompkins  wrote:
> 
> Hello,
> 
> Commons Jelly 1.0.1 RC3 is available for review here:
>  https://dist.apache.org/repos/dist/dev/commons/jelly (svn revision 21410)
> 
> The tag is here:
>  
> https://svn.apache.org/repos/asf/commons/proper/jelly/tags/commons-jelly-1.0.1-RC3
> 
> Commit the tag points at:
>  1807023
> 
> Maven Artifacts:
>  https://repository.apache.org/content/repositories/orgapachecommons-1261
> 
> These are the Maven artifacts and their hashes:
> 
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-javadoc.jar
> 
> (SHA1: 1ccd4030ed815d9b3f3b020c0b9e212f709b)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-sources.jar.asc
> 
> (SHA1: 36657bc375f8dcade51d1dbd067a80126895b41e)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.pom.asc
> 
> (SHA1: b77f35770a0476d575b777130f5629693e292374)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.pom
> 
> (SHA1: 65333d0abdce02b3ae3a54c513c19b7aa04749ba)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.jar.asc
> 
> (SHA1: 6f6b0cd5bf67fce3e176208fb89e8f5a9a7fd517)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-javadoc.jar.asc
> 
> (SHA1: 73d76f9bf582799717c42eaa951885933231d62e)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-sources.jar
> 
> (SHA1: dbc0153a76f706f4cb44f5631633157adbeb6a4d)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.jar
> 
> (SHA1: 8ef47080d6baf4910f4707e3ce5612d32cd17fc0)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-tests.jar.asc
> 
> (SHA1: cb34a2dfac65164f1a214d99e0701064fd251172)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-test-sources.jar.asc
> 
> (SHA1: 868f8155ad8cddcbe3f72367091b9787d7b002b6)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-test-sources.jar
> 
> (SHA1: e1f7a6949a3d452b32236f1eec91b1629fec847b)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-tests.jar
> 
> (SHA1: 58ed6f095e6159a202c75fe62f08137a14814e7c)
> 
> I have tested this with JDK 1.5.0_22-b03 using Ant 1.6.0. Notes on building 
> can be found in the 
> BUILDING.md included in the source distributions.
> 
> Details of changes since 1.0 are in the release notes:
>https://dist.apache.org/repos/dist/dev/commons/jelly/RELEASE-NOTES.txt
> 
> Site:
>  I have no site as this was generated with ant. My plan was to simply 
> make minimal 
>  changes to the existent site for the purpose of documenting the patch.
> 
> KEYS:
>  https://www.apache.org/dist/commons/KEYS
> 
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now,
> i.e. sometime after 02:40 (UTC) 5-September 2017
> 
>  [ ] +1 Release these artifacts
>  [ ] +0 OK, but...
>  [ ] -0 OK, but really should fix...
>  [ ] -1 I oppose this release because...
> 
> Thanks!
> Rob


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-text pull request #55: TEXT-97: RandomStringGenerator able to pass m...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/commons-text/pull/55


---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [JCS] missing 2.2 release in jira?

[Romain Manni-Bucau]

That's what I had in mind,

@Thomas: can you say a word on the diff between 2.3 and 2.2 if you have it
still in memory please?


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | JavaEE Factory


2017-09-05 20:27 GMT+02:00 Gary Gregory :

> On Sun, Sep 3, 2017 at 11:42 PM, Romain Manni-Bucau  >
> wrote:
>
> > Hmm 2 questions just to ensure we are aligned and mail didn't loose
> > information:
> >
> > - for trunk: do we move the version to 2.3-SNAPSHOT?
> >
>
> If you expect the next version to include _minor_ changes (like minor new
> features), then 2.3-SNAPSHOT is fine. If you are only going to fix bugs,
> then 2.3.1-SNAPSHOT would be appropriate.
>
>
> > - for next release: i'm not sure what's the difference is at the moment
> but
> > any reason to not do a 2.3 from trunk? (asking from the jcache
> perspective
> > i upgraded to the "snapshot" without issues)
> >
>
> Seems OK to me.
>
> Gary
>
>
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github  > rmannibucau> |
> > LinkedIn  | JavaEE Factory
> > 
> >
> > 2017-09-03 22:19 GMT+02:00 Thomas Vandahl :
> >
> > > On 03.09.17 20:17, Romain Manni-Bucau wrote:
> > > > Thanks Thomas
> > > >
> > > > Is it the same for the code? Just realised pom were not up to date
> too.
> > >
> > > I released from a branch as some braking changes are already checked in
> > > into trunk. I'd kindly ask you to do the same if you are planning for a
> > > bugfix release.
> > >
> > > Bye, Thomas.
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
>

Re: [LANG] Releasing 3.6.1

[Rob Tompkins]

> On Sep 5, 2017, at 11:00 AM, Amey Jadiye  wrote:
> 
> Hello Benedikt,
> 
> How about we keep that deprecated in lang and release Text-1.2 ?
[snip]

I’m on board with this if folks are complaining and the original intent was to 
deprecate things in [lang]. Why not roll forward as opposed to backwards? 

But, that opens the question: Is RandomStringUtils something that most folks 
would want (i.e. should it be in [lang] or [text])? I think that question is 
more the heart of the problem here. Either direction seems reasonable to me.

Thoughts?

-Rob

> I will
> submit changes [1] related to this in fact i'm fixing couple of failing
> test cases ATM. If you are planning to release 3.6.1 just to remove
> deprecation and  deprecate RandomStringUtils back in Lang - 3.7 I'm fine
> with that as well.
> 
> [1]. https://issues.apache.org/jira/browse/TEXT-101
> 
> On Tue, Sep 5, 2017 at 10:47 AM, Benedikt Ritter  wrote:
> 
>> Hi,
>> 
>> since we’re getting more and more requests about the deprecation of
>> RandomStringUtils, I’m thinking about releasing the current state of the
>> master branch as 3.6.1. I may have time to push an RC sometime this week.
>> So if you have some fixes you want to include, please do so now.
>> 
>> Regards,
>> Benedikt
>> -
>> 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

Re: [JCS] missing 2.2 release in jira?

[Gary Gregory]

On Sun, Sep 3, 2017 at 11:42 PM, Romain Manni-Bucau 
wrote:

> Hmm 2 questions just to ensure we are aligned and mail didn't loose
> information:
>
> - for trunk: do we move the version to 2.3-SNAPSHOT?
>

If you expect the next version to include _minor_ changes (like minor new
features), then 2.3-SNAPSHOT is fine. If you are only going to fix bugs,
then 2.3.1-SNAPSHOT would be appropriate.


> - for next release: i'm not sure what's the difference is at the moment but
> any reason to not do a 2.3 from trunk? (asking from the jcache perspective
> i upgraded to the "snapshot" without issues)
>

Seems OK to me.

Gary


>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  rmannibucau> |
> LinkedIn  | JavaEE Factory
> 
>
> 2017-09-03 22:19 GMT+02:00 Thomas Vandahl :
>
> > On 03.09.17 20:17, Romain Manni-Bucau wrote:
> > > Thanks Thomas
> > >
> > > Is it the same for the code? Just realised pom were not up to date too.
> >
> > I released from a branch as some braking changes are already checked in
> > into trunk. I'd kindly ask you to do the same if you are planning for a
> > bugfix release.
> >
> > Bye, Thomas.
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: [JCS] update to Log4j 2 facade API

[Romain Manni-Bucau]

@Ralph: not exactly, if you check tomee/meecowave/cxf, all have Logger
implementations backed by something else. Integration is more or less good
depending the requirements but extending logger you get an implementation
almost as fast as a native log4j. It keeps JUL as API which also allows a
dependency free solution. Only constraint is to create the jul Logger
through a framework factory if you don't want to depend on the LogManager
which is sadly set only on the JVM. The integration (Log4j2Logger) could be
owned by log4j2 (i assume it is in jul integration maybe?). It is better
than a handler since it bypasses jul completely when switching and goes on
the impl directly. Summary is "jul is bad" doesnt mean dont use jul since
you can make it good and stay dependency free for frameworks which is quite
important for not final dependencies (= you dont know if the app is used in
a final app or as a library in a stack).


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | JavaEE Factory


2017-09-05 20:13 GMT+02:00 Gary Gregory :

> On Tue, Sep 5, 2017 at 11:03 AM, Ralph Goers 
> wrote:
>
> >
> > > On Sep 5, 2017, at 9:19 AM, Romain Manni-Bucau 
> > wrote:
> > >
> > > Le 5 sept. 2017 17:35, "Ralph Goers"  > > a écrit :
> > >
> > >
> > >> On Sep 5, 2017, at 6:45 AM, Romain Manni-Bucau  >
> > > wrote:
> > >>
> > >>>
> > >>
> > >> I think it must go the other way: log4j2 must push projects to move
> > >> otherwise projects will be happy with X -> log4j2 bridges, no?
> > >
> > > We already have support for bridging other APIs to Log4j 2.
> > >
> > >
> > > Not bypassing jul impl without a logmanager right? That is what does
> > > frameworks api
> >
> > Is what you are asking for the same as what is asked for in
> > https://issues.apache.org/jira/browse/LOG4J2-2025? <
> > https://issues.apache.org/jira/browse/LOG4J2-2025?> If so, I am planning
> > on doing that although that integration will not make users very happy.
> > This is one of the reasons that jul sucks.
> >
>
> Ralph,
>
> Do you want to assign that issue to yourself? That would allow others to
> focus on different tickets.
>
> Gary
>
>
> >
> > Ralph
>

Re: [JCS] update to Log4j 2 facade API

[Gary Gregory]

On Tue, Sep 5, 2017 at 11:03 AM, Ralph Goers 
wrote:

>
> > On Sep 5, 2017, at 9:19 AM, Romain Manni-Bucau 
> wrote:
> >
> > Le 5 sept. 2017 17:35, "Ralph Goers"  > a écrit :
> >
> >
> >> On Sep 5, 2017, at 6:45 AM, Romain Manni-Bucau 
> > wrote:
> >>
> >>>
> >>
> >> I think it must go the other way: log4j2 must push projects to move
> >> otherwise projects will be happy with X -> log4j2 bridges, no?
> >
> > We already have support for bridging other APIs to Log4j 2.
> >
> >
> > Not bypassing jul impl without a logmanager right? That is what does
> > frameworks api
>
> Is what you are asking for the same as what is asked for in
> https://issues.apache.org/jira/browse/LOG4J2-2025? <
> https://issues.apache.org/jira/browse/LOG4J2-2025?> If so, I am planning
> on doing that although that integration will not make users very happy.
> This is one of the reasons that jul sucks.
>

Ralph,

Do you want to assign that issue to yourself? That would allow others to
focus on different tickets.

Gary


>
> Ralph

Re: [JCS] update to Log4j 2 facade API

[Ralph Goers]

> On Sep 5, 2017, at 9:19 AM, Romain Manni-Bucau  wrote:
> 
> Le 5 sept. 2017 17:35, "Ralph Goers"  > a écrit :
> 
> 
>> On Sep 5, 2017, at 6:45 AM, Romain Manni-Bucau 
> wrote:
>> 
>>> 
>> 
>> I think it must go the other way: log4j2 must push projects to move
>> otherwise projects will be happy with X -> log4j2 bridges, no?
> 
> We already have support for bridging other APIs to Log4j 2.
> 
> 
> Not bypassing jul impl without a logmanager right? That is what does
> frameworks api

Is what you are asking for the same as what is asked for in 
https://issues.apache.org/jira/browse/LOG4J2-2025? 
 If so, I am planning on 
doing that although that integration will not make users very happy. This is 
one of the reasons that jul sucks.

Ralph

Re: [JCS] update to Log4j 2 facade API

[Romain Manni-Bucau]

Le 5 sept. 2017 17:35, "Ralph Goers"  a écrit :


> On Sep 5, 2017, at 6:45 AM, Romain Manni-Bucau 
wrote:
>
> 2017-09-05 15:33 GMT+02:00 Ralph Goers :
>>
>> I see your point. I guess we never built a bridge from the Log4j 2 API to
>> JUL simply because we couldn’t imagine anyone would want to use it :-)
As I
>> said, by choosing jul you have gone with the worst option. You would have
>> been better off creating your own API.
>>
>> I think you will see in my original email I said that containers are a
>> special case - either they should hide all the third party dependencies
>> they use or they should use their own logging abstraction. It sounds like
>> TomEE doesn’t do either of these.
>>
>
> It is more complicated, tomee does for the code it owns, as well as cxf,
> owb,  but the most consistent API is JUL for all of them (most of them
> even just subclass JUL to allow extension). It looks doable to be fast
with
> JUL since you can override Logger completely so I'm tempted to say that in
> term of API not that impacting until you use very advanced signature
(which
> is not the case of container stacks in general).
>
>
>>
>> If you need an adapter from the Log4j 2 API to a TomEE implementation
just
>> create a Jira issue at Log4j 2. I am sure we would be happy to provide
it.
>>
>
> I think it must go the other way: log4j2 must push projects to move
> otherwise projects will be happy with X -> log4j2 bridges, no?

We already have support for bridging other APIs to Log4j 2.


Not bypassing jul impl without a logmanager right? That is what does
frameworks api


Ralph

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-text issue #55: TEXT-97: RandomStringGenerator able to pass multiple...

[ameyjadiye]

Github user ameyjadiye commented on the issue:

https://github.com/apache/commons-text/pull/55
  
@chtompki , I'm sorry for such short note, 2.x was for making .builder() 
static, PR seems ok for accepting in 1.2 release, you might want to go though 
jira as well.


---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-text issue #55: TEXT-97: RandomStringGenerator able to pass multiple...

[chtompki]

Github user chtompki commented on the issue:

https://github.com/apache/commons-text/pull/55
  
Pardon...I don't see why this would necessitate a 2.X. Let me re-read.


---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-text issue #55: TEXT-97: RandomStringGenerator able to pass multiple...

[chtompki]

Github user chtompki commented on the issue:

https://github.com/apache/commons-text/pull/55
  
Are we ready to do a change that would necessitate a 2.X?


---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [JCS] update to Log4j 2 facade API

[Ralph Goers]

> On Sep 5, 2017, at 6:45 AM, Romain Manni-Bucau  wrote:
> 
> 2017-09-05 15:33 GMT+02:00 Ralph Goers :
>> 
>> I see your point. I guess we never built a bridge from the Log4j 2 API to
>> JUL simply because we couldn’t imagine anyone would want to use it :-) As I
>> said, by choosing jul you have gone with the worst option. You would have
>> been better off creating your own API.
>> 
>> I think you will see in my original email I said that containers are a
>> special case - either they should hide all the third party dependencies
>> they use or they should use their own logging abstraction. It sounds like
>> TomEE doesn’t do either of these.
>> 
> 
> It is more complicated, tomee does for the code it owns, as well as cxf,
> owb,  but the most consistent API is JUL for all of them (most of them
> even just subclass JUL to allow extension). It looks doable to be fast with
> JUL since you can override Logger completely so I'm tempted to say that in
> term of API not that impacting until you use very advanced signature (which
> is not the case of container stacks in general).
> 
> 
>> 
>> If you need an adapter from the Log4j 2 API to a TomEE implementation just
>> create a Jira issue at Log4j 2. I am sure we would be happy to provide it.
>> 
> 
> I think it must go the other way: log4j2 must push projects to move
> otherwise projects will be happy with X -> log4j2 bridges, no?

We already have support for bridging other APIs to Log4j 2.

Ralph

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [LANG] Releasing 3.6.1

[Amey Jadiye]

Hello Benedikt,

How about we keep that deprecated in lang and release Text-1.2 ? I will
submit changes [1] related to this in fact i'm fixing couple of failing
test cases ATM. If you are planning to release 3.6.1 just to remove
deprecation and  deprecate RandomStringUtils back in Lang - 3.7 I'm fine
with that as well.

[1]. https://issues.apache.org/jira/browse/TEXT-101

On Tue, Sep 5, 2017 at 10:47 AM, Benedikt Ritter  wrote:

> Hi,
>
> since we’re getting more and more requests about the deprecation of
> RandomStringUtils, I’m thinking about releasing the current state of the
> master branch as 3.6.1. I may have time to push an RC sometime this week.
> So if you have some fixes you want to include, please do so now.
>
> Regards,
> Benedikt
> -
> 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: [JCS] update to Log4j 2 facade API

[Matt Sicker]

The log4j-api to JUL bridge would be for users who have a JUL logging
config already that don't want to change, but do want all code to log to
the same location.

On 5 September 2017 at 08:45, Romain Manni-Bucau 
wrote:

> 2017-09-05 15:33 GMT+02:00 Ralph Goers :
>
> >
> > > On Sep 5, 2017, at 12:11 AM, Romain Manni-Bucau  >
> > wrote:
> > >
> > > 2017-09-05 9:01 GMT+02:00 Apache  > ralph.go...@dslextreme.com>>:
> > >
> > >>
> > >>
> > >>
> > >> Sent from my iPad
> > >>> On Sep 4, 2017, at 10:03 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > >> wrote:
> > >>>
> > >>> Le 5 sept. 2017 05:40, "Ralph Goers"  a
> > >> écrit :
> > >>>
> > >>>
> >  On Sep 4, 2017, at 2:24 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > >>> wrote:
> > 
> >  Le 4 sept. 2017 20:44, "Matt Sicker"  a écrit :
> > 
> >  You don't duplicate any logging config. You can use both slf4j-api
> and
> >  log4j-api with either logback or log4j2.
> > 
> > 
> >  Except you dont always have the choice with 2 apis. It also messes
> up
> >  logging lifecycle and setup which needs 2 integrations in the
> > >> environment.
> >  Whatever reason you use it is not free to switch and even if log4j2
> is
> >  awesome, it is far to be a first citizen api for a common library
> used
> > >> in
> > >>> a
> >  lot of contexts IMHO.
> > >>>
> > >>> Now you have me curious about your last sentence. In you opinion,
> what
> > is
> > >>> keeping Log4j2 from being a first citizen api for a common library?
> You
> > >>> didn’t mention SLF4J in that sentence so I am assuming you consider
> it
> > to
> > >>> be one. Why?
> > >>>
> > >>>
> > >>> Purely usages as an api. Once again the fact I'm very cautious moving
> > to
> > >>> log4j2 api is not about the quality of log4j2. Take most of asf
> project
> > >>> stacks and I guess slf4j, jul or even commons logging will be more
> used
> > >>> than log4j2 as an API. Side question: wonder if we can extract this
> > stat
> > >>> through asf infra?
> > >>>
> > >>> I hear the "if noone starts" side of the issue but it must be more
> > global
> > >>> than just one lib by lib (a bit like when tomee needs to support one
> > more
> > >>> java version and upgrades asm in openjpa, cxf, tomee, owb, ... at
> > once).
> > >>>
> > >>
> > >> You can look at the download stats from repository.apache.org. You
> will
> > >> see there are more downloads of the API than Log4J-core, but to be
> > honest I
> > >> have no idea what that means. I am just happy that the trend keeps
> > going up.
> > >>
> > >> What does it really matter if it used more (or less) as an API? What
> > >> matters most is how well it works for you and your users. In addition,
> > if
> > >> you look at the Github and Jira stats you will see that Log4J has been
> > far
> > >> more active over the last few years, so you are much more likely to
> get
> > >> better support.
> > >>
> > >
> > > I think we agree on the user first point but not on what it means. By
> > > itself log4j2 is awesome but in a container it just leads to issue
> until
> > > the whole stack is log4j2. Just take tomee 7 webprofile (which is 1/3
> of
> > > the full distribution and not that far from a user app in term of
> stack):
> > > - cxf
> > > - tomcat
> > > - [beanutils]
> > > - [collections]
> > > - [dbcp2]
> > > - [digester]
> > > - [lang3]
> > > - [pool2]
> > > - geronimo-javamail
> > > - geronimo-transaction
> > > - hsqldb
> > > - johnzon
> > > - myfaces
> > > - openejb/tomee
> > > - openwebbeans
> > > - quartz
> > > - xbean
> > >
> > > How many use log4j2-api? None. All have potential bridges based on JUL,
> > > slf4j or [logging] but none use log4j2. Now assume you make log4j2 an
> api
> > > of jcs which fall into tomee+, then we need to add log4j2 api
> > > with a jul implementation by defaut or change the logging stack which
> is
> > > likely not an option and would lead to inconsistencies with tomcat
> (would
> > > break tomee philosophy).
> > >
> > > So we are back to my last point: either somebody has enough time to PR
> > and
> > > get it merged on all projects (if "limited" to asf it would already
> > enable
> > > it I think) at ~once and then log4j2 could be seen as an API and good
> > > replacement of slf4j/[logging] or this fight will always block at
> > > integration level. Once again it is not about the log4j2 quality but
> more
> > > the overall ecosystem.
> > >
> >
> >
> > I see your point. I guess we never built a bridge from the Log4j 2 API to
> > JUL simply because we couldn’t imagine anyone would want to use it :-)
> As I
> > said, by choosing jul you have gone with the worst option. You would have
> > been better off creating your own API.
> >
> > I think you will see in my original email I said that containers are a
> > special case - either they should hide all the third party dependencies
> > they use or they should use their own logging abstraction. It sounds like
> > TomEE doesn’t do either of thes

[GitHub] commons-text issue #55: TEXT-97: RandomStringGenerator able to pass multiple...

[ameyjadiye]

Github user ameyjadiye commented on the issue:

https://github.com/apache/commons-text/pull/55
  
@chtompki , If possible can you review and accept this ? I need this for 
TEXT-101.


---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [JCS] update to Log4j 2 facade API

[Romain Manni-Bucau]

2017-09-05 15:33 GMT+02:00 Ralph Goers :

>
> > On Sep 5, 2017, at 12:11 AM, Romain Manni-Bucau 
> wrote:
> >
> > 2017-09-05 9:01 GMT+02:00 Apache  ralph.go...@dslextreme.com>>:
> >
> >>
> >>
> >>
> >> Sent from my iPad
> >>> On Sep 4, 2017, at 10:03 PM, Romain Manni-Bucau  >
> >> wrote:
> >>>
> >>> Le 5 sept. 2017 05:40, "Ralph Goers"  a
> >> écrit :
> >>>
> >>>
>  On Sep 4, 2017, at 2:24 PM, Romain Manni-Bucau  >
> >>> wrote:
> 
>  Le 4 sept. 2017 20:44, "Matt Sicker"  a écrit :
> 
>  You don't duplicate any logging config. You can use both slf4j-api and
>  log4j-api with either logback or log4j2.
> 
> 
>  Except you dont always have the choice with 2 apis. It also messes up
>  logging lifecycle and setup which needs 2 integrations in the
> >> environment.
>  Whatever reason you use it is not free to switch and even if log4j2 is
>  awesome, it is far to be a first citizen api for a common library used
> >> in
> >>> a
>  lot of contexts IMHO.
> >>>
> >>> Now you have me curious about your last sentence. In you opinion, what
> is
> >>> keeping Log4j2 from being a first citizen api for a common library? You
> >>> didn’t mention SLF4J in that sentence so I am assuming you consider it
> to
> >>> be one. Why?
> >>>
> >>>
> >>> Purely usages as an api. Once again the fact I'm very cautious moving
> to
> >>> log4j2 api is not about the quality of log4j2. Take most of asf project
> >>> stacks and I guess slf4j, jul or even commons logging will be more used
> >>> than log4j2 as an API. Side question: wonder if we can extract this
> stat
> >>> through asf infra?
> >>>
> >>> I hear the "if noone starts" side of the issue but it must be more
> global
> >>> than just one lib by lib (a bit like when tomee needs to support one
> more
> >>> java version and upgrades asm in openjpa, cxf, tomee, owb, ... at
> once).
> >>>
> >>
> >> You can look at the download stats from repository.apache.org. You will
> >> see there are more downloads of the API than Log4J-core, but to be
> honest I
> >> have no idea what that means. I am just happy that the trend keeps
> going up.
> >>
> >> What does it really matter if it used more (or less) as an API? What
> >> matters most is how well it works for you and your users. In addition,
> if
> >> you look at the Github and Jira stats you will see that Log4J has been
> far
> >> more active over the last few years, so you are much more likely to get
> >> better support.
> >>
> >
> > I think we agree on the user first point but not on what it means. By
> > itself log4j2 is awesome but in a container it just leads to issue until
> > the whole stack is log4j2. Just take tomee 7 webprofile (which is 1/3 of
> > the full distribution and not that far from a user app in term of stack):
> > - cxf
> > - tomcat
> > - [beanutils]
> > - [collections]
> > - [dbcp2]
> > - [digester]
> > - [lang3]
> > - [pool2]
> > - geronimo-javamail
> > - geronimo-transaction
> > - hsqldb
> > - johnzon
> > - myfaces
> > - openejb/tomee
> > - openwebbeans
> > - quartz
> > - xbean
> >
> > How many use log4j2-api? None. All have potential bridges based on JUL,
> > slf4j or [logging] but none use log4j2. Now assume you make log4j2 an api
> > of jcs which fall into tomee+, then we need to add log4j2 api
> > with a jul implementation by defaut or change the logging stack which is
> > likely not an option and would lead to inconsistencies with tomcat (would
> > break tomee philosophy).
> >
> > So we are back to my last point: either somebody has enough time to PR
> and
> > get it merged on all projects (if "limited" to asf it would already
> enable
> > it I think) at ~once and then log4j2 could be seen as an API and good
> > replacement of slf4j/[logging] or this fight will always block at
> > integration level. Once again it is not about the log4j2 quality but more
> > the overall ecosystem.
> >
>
>
> I see your point. I guess we never built a bridge from the Log4j 2 API to
> JUL simply because we couldn’t imagine anyone would want to use it :-) As I
> said, by choosing jul you have gone with the worst option. You would have
> been better off creating your own API.
>
> I think you will see in my original email I said that containers are a
> special case - either they should hide all the third party dependencies
> they use or they should use their own logging abstraction. It sounds like
> TomEE doesn’t do either of these.
>

It is more complicated, tomee does for the code it owns, as well as cxf,
owb,  but the most consistent API is JUL for all of them (most of them
even just subclass JUL to allow extension). It looks doable to be fast with
JUL since you can override Logger completely so I'm tempted to say that in
term of API not that impacting until you use very advanced signature (which
is not the case of container stacks in general).


>
> If you need an adapter from the Log4j 2 API to a TomEE implementation just
> create a Jira issue at Log4j 2. I am sure we would be hap

Re: [JCS] update to Log4j 2 facade API

[Ralph Goers]

> On Sep 5, 2017, at 12:11 AM, Romain Manni-Bucau  wrote:
> 
> 2017-09-05 9:01 GMT+02:00 Apache  >:
> 
>> 
>> 
>> 
>> Sent from my iPad
>>> On Sep 4, 2017, at 10:03 PM, Romain Manni-Bucau 
>> wrote:
>>> 
>>> Le 5 sept. 2017 05:40, "Ralph Goers"  a
>> écrit :
>>> 
>>> 
 On Sep 4, 2017, at 2:24 PM, Romain Manni-Bucau 
>>> wrote:
 
 Le 4 sept. 2017 20:44, "Matt Sicker"  a écrit :
 
 You don't duplicate any logging config. You can use both slf4j-api and
 log4j-api with either logback or log4j2.
 
 
 Except you dont always have the choice with 2 apis. It also messes up
 logging lifecycle and setup which needs 2 integrations in the
>> environment.
 Whatever reason you use it is not free to switch and even if log4j2 is
 awesome, it is far to be a first citizen api for a common library used
>> in
>>> a
 lot of contexts IMHO.
>>> 
>>> Now you have me curious about your last sentence. In you opinion, what is
>>> keeping Log4j2 from being a first citizen api for a common library? You
>>> didn’t mention SLF4J in that sentence so I am assuming you consider it to
>>> be one. Why?
>>> 
>>> 
>>> Purely usages as an api. Once again the fact I'm very cautious moving to
>>> log4j2 api is not about the quality of log4j2. Take most of asf project
>>> stacks and I guess slf4j, jul or even commons logging will be more used
>>> than log4j2 as an API. Side question: wonder if we can extract this stat
>>> through asf infra?
>>> 
>>> I hear the "if noone starts" side of the issue but it must be more global
>>> than just one lib by lib (a bit like when tomee needs to support one more
>>> java version and upgrades asm in openjpa, cxf, tomee, owb, ... at once).
>>> 
>> 
>> You can look at the download stats from repository.apache.org. You will
>> see there are more downloads of the API than Log4J-core, but to be honest I
>> have no idea what that means. I am just happy that the trend keeps going up.
>> 
>> What does it really matter if it used more (or less) as an API? What
>> matters most is how well it works for you and your users. In addition, if
>> you look at the Github and Jira stats you will see that Log4J has been far
>> more active over the last few years, so you are much more likely to get
>> better support.
>> 
> 
> I think we agree on the user first point but not on what it means. By
> itself log4j2 is awesome but in a container it just leads to issue until
> the whole stack is log4j2. Just take tomee 7 webprofile (which is 1/3 of
> the full distribution and not that far from a user app in term of stack):
> - cxf
> - tomcat
> - [beanutils]
> - [collections]
> - [dbcp2]
> - [digester]
> - [lang3]
> - [pool2]
> - geronimo-javamail
> - geronimo-transaction
> - hsqldb
> - johnzon
> - myfaces
> - openejb/tomee
> - openwebbeans
> - quartz
> - xbean
> 
> How many use log4j2-api? None. All have potential bridges based on JUL,
> slf4j or [logging] but none use log4j2. Now assume you make log4j2 an api
> of jcs which fall into tomee+, then we need to add log4j2 api
> with a jul implementation by defaut or change the logging stack which is
> likely not an option and would lead to inconsistencies with tomcat (would
> break tomee philosophy).
> 
> So we are back to my last point: either somebody has enough time to PR and
> get it merged on all projects (if "limited" to asf it would already enable
> it I think) at ~once and then log4j2 could be seen as an API and good
> replacement of slf4j/[logging] or this fight will always block at
> integration level. Once again it is not about the log4j2 quality but more
> the overall ecosystem.
> 


I see your point. I guess we never built a bridge from the Log4j 2 API to JUL 
simply because we couldn’t imagine anyone would want to use it :-) As I said, 
by choosing jul you have gone with the worst option. You would have been better 
off creating your own API.

I think you will see in my original email I said that containers are a special 
case - either they should hide all the third party dependencies they use or 
they should use their own logging abstraction. It sounds like TomEE doesn’t do 
either of these.

If you need an adapter from the Log4j 2 API to a TomEE implementation just 
create a Jira issue at Log4j 2. I am sure we would be happy to provide it.

Ralph

Re: [All][Math] New component: "Commons Geometry"?

[Emmanuel Bourg]

Le 4/09/2017 à 15:30, Gilles a écrit :

> I see it as a fundamental one: Why should codes unrelated
> by scope be artificially tied together by management rules
> (such as design, supported language version, release schedule,
> etc.)?[1]

Because they share the same general scope of being math related. The
design and the supported language version can be different for each module.


> Why do you "prefer" multi-module, independently of the subject
> matters being talked about?

I already explained twice in this thread.


> Please comment on my suggestion to create a single maven project
> for the whole of "Commons".  I'd agree that this suggestion is
> ridiculous; yet some of you do the same proposal for "everything
> math-related".

If you want to use an absurd proposal to prove your point let me try
that game too: Please comment on my suggestion to create multiple
components out of every Java package defined in the Commons components.


> If you had been contributing to the math codes (plural), you
> perhaps would have understood that it creates more management
> problems than it solves.[4]

Please use foot references for external links only, your messages are
unreadable if we have to go back and forth to understand them.


> Again, I have to stress on what happened that led me to propose
> a new "Commons RNG": obvious improvements to the CM code base
> were outrightly rejected based on demonstrably false statements;
> i.e. the objections were not technical but for the convenience
> of one user.

I still think that splitting RNG into its own component was a good move.
I'm less happy with Numbers, I'd have preferred a module from a
renovated "CM5" project started from scratch as I'm suggesting now for
Geometry.


> Do you think that I enjoy contradicting you on these matters?

I'm starting to think that you enjoy rhetoric, probably more than
seeking compromise unfortunately.


> Do they want to implement another plan?  What plan?

Here is my counter-proposal:

1. Refactor Commons Math as a multi-module project, bump to version 5
2. Create two modules: geometry and legacy
3. Release Commons Math 5, without the legacy module
4. Spin-off new modules from the legacy module when needed

And I'm willing to help at least for the steps 1 and 2.

Emmanuel Bourg

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [JCS] update to Log4j 2 facade API

[Romain Manni-Bucau]

2017-09-05 9:01 GMT+02:00 Apache :

>
>
>
> Sent from my iPad
> > On Sep 4, 2017, at 10:03 PM, Romain Manni-Bucau 
> wrote:
> >
> > Le 5 sept. 2017 05:40, "Ralph Goers"  a
> écrit :
> >
> >
> >> On Sep 4, 2017, at 2:24 PM, Romain Manni-Bucau 
> > wrote:
> >>
> >> Le 4 sept. 2017 20:44, "Matt Sicker"  a écrit :
> >>
> >> You don't duplicate any logging config. You can use both slf4j-api and
> >> log4j-api with either logback or log4j2.
> >>
> >>
> >> Except you dont always have the choice with 2 apis. It also messes up
> >> logging lifecycle and setup which needs 2 integrations in the
> environment.
> >> Whatever reason you use it is not free to switch and even if log4j2 is
> >> awesome, it is far to be a first citizen api for a common library used
> in
> > a
> >> lot of contexts IMHO.
> >
> > Now you have me curious about your last sentence. In you opinion, what is
> > keeping Log4j2 from being a first citizen api for a common library? You
> > didn’t mention SLF4J in that sentence so I am assuming you consider it to
> > be one. Why?
> >
> >
> > Purely usages as an api. Once again the fact I'm very cautious moving to
> > log4j2 api is not about the quality of log4j2. Take most of asf project
> > stacks and I guess slf4j, jul or even commons logging will be more used
> > than log4j2 as an API. Side question: wonder if we can extract this stat
> > through asf infra?
> >
> > I hear the "if noone starts" side of the issue but it must be more global
> > than just one lib by lib (a bit like when tomee needs to support one more
> > java version and upgrades asm in openjpa, cxf, tomee, owb, ... at once).
> >
>
> You can look at the download stats from repository.apache.org. You will
> see there are more downloads of the API than Log4J-core, but to be honest I
> have no idea what that means. I am just happy that the trend keeps going up.
>
> What does it really matter if it used more (or less) as an API? What
> matters most is how well it works for you and your users. In addition, if
> you look at the Github and Jira stats you will see that Log4J has been far
> more active over the last few years, so you are much more likely to get
> better support.
>

I think we agree on the user first point but not on what it means. By
itself log4j2 is awesome but in a container it just leads to issue until
the whole stack is log4j2. Just take tomee 7 webprofile (which is 1/3 of
the full distribution and not that far from a user app in term of stack):
- cxf
- tomcat
- [beanutils]
- [collections]
- [dbcp2]
- [digester]
- [lang3]
- [pool2]
- geronimo-javamail
- geronimo-transaction
- hsqldb
- johnzon
- myfaces
- openejb/tomee
- openwebbeans
- quartz
- xbean

How many use log4j2-api? None. All have potential bridges based on JUL,
slf4j or [logging] but none use log4j2. Now assume you make log4j2 an api
of jcs which fall into tomee+, then we need to add log4j2 api
with a jul implementation by defaut or change the logging stack which is
likely not an option and would lead to inconsistencies with tomcat (would
break tomee philosophy).

So we are back to my last point: either somebody has enough time to PR and
get it merged on all projects (if "limited" to asf it would already enable
it I think) at ~once and then log4j2 could be seen as an API and good
replacement of slf4j/[logging] or this fight will always block at
integration level. Once again it is not about the log4j2 quality but more
the overall ecosystem.


>
> Ralph
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [JCS] update to Log4j 2 facade API

[Apache]

Sent from my iPad
> On Sep 4, 2017, at 10:03 PM, Romain Manni-Bucau  wrote:
> 
> Le 5 sept. 2017 05:40, "Ralph Goers"  a écrit :
> 
> 
>> On Sep 4, 2017, at 2:24 PM, Romain Manni-Bucau 
> wrote:
>> 
>> Le 4 sept. 2017 20:44, "Matt Sicker"  a écrit :
>> 
>> You don't duplicate any logging config. You can use both slf4j-api and
>> log4j-api with either logback or log4j2.
>> 
>> 
>> Except you dont always have the choice with 2 apis. It also messes up
>> logging lifecycle and setup which needs 2 integrations in the environment.
>> Whatever reason you use it is not free to switch and even if log4j2 is
>> awesome, it is far to be a first citizen api for a common library used in
> a
>> lot of contexts IMHO.
> 
> Now you have me curious about your last sentence. In you opinion, what is
> keeping Log4j2 from being a first citizen api for a common library? You
> didn’t mention SLF4J in that sentence so I am assuming you consider it to
> be one. Why?
> 
> 
> Purely usages as an api. Once again the fact I'm very cautious moving to
> log4j2 api is not about the quality of log4j2. Take most of asf project
> stacks and I guess slf4j, jul or even commons logging will be more used
> than log4j2 as an API. Side question: wonder if we can extract this stat
> through asf infra?
> 
> I hear the "if noone starts" side of the issue but it must be more global
> than just one lib by lib (a bit like when tomee needs to support one more
> java version and upgrades asm in openjpa, cxf, tomee, owb, ... at once).
> 

You can look at the download stats from repository.apache.org. You will see 
there are more downloads of the API than Log4J-core, but to be honest I have no 
idea what that means. I am just happy that the trend keeps going up.

What does it really matter if it used more (or less) as an API? What matters 
most is how well it works for you and your users. In addition, if you look at 
the Github and Jira stats you will see that Log4J has been far more active over 
the last few years, so you are much more likely to get better support.

Ralph


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org